Why not have Michelson target the ethereum virtual machine instead of creating a whole new protocol? Besides the provability of contracts, are there other advantages over eth?
The tezos protocal has a major innovation over others: formal governance by the owners of the tokens. It is also proof of stake from the beginning. In general they have made a lot of smart design decisions as documented in their publications going back several years.
They have been slow to launch though. While they might have had a lead on Ether, it is now to be seen how the market reacts to their sale.
Interestingly, and personally I'm not sure correctly, the ethereum community seems to have rejected governance by stake alone. There is a tool, carbonvote.com, that enables voting by stake, but the community has recently rejected a vote because of the impact on and position of other stakeholders: users, miners, and devs.
It's worth solving precisely because they are so new.
If they were old, there would be one, obvious, correct design to follow. However, no one knows precisely what the right formula is yet. This has led to a situation where projects either stagnate -- Bitcoin as network has been unable to integrate important innovations despite the incredible talent of the people working on it -- or build a strong coupling to a central organization, which can threaten their decentralized nature.
How do you design a decentralized protocol that can keep up to date with innovation in this space and yet remain decentralized? That's the problem the governance model is trying to solve.
(imo 80% is more than enough to prevent shenanigans -- in most contexts anything even slightly controversial cannot get near 80% support. And in this case, the voting is weighted by stake, and the market value of the Tez would presumably decrease if shenanigans were pulled; Tez-holders would probably be reluctant to do something that is both wrong and also would clearly decrease the value of their holdings. In fact i think the threshold for amendment should be lower than 80%; i might chose 67% if it were up to me)
It's possible to write provable programs in any language, but some formalisms make proofs easier than other. I think Michelson makes it easier. There are a few other advantages I can think of:
1) The code can be inspected directly on the blockchain and remain human readable. You can attach Solidity code to an Ethereum contract, but there is no certified compiler yet so you can't be sure they do the same thing.
2) Type safety and an insistence on functional design make good things happen. For instance, by insisting from the get go that contracts should be pure functions, we naturally make it hard to write DAO-like reentrancy bugs. By typing every input, we avoid the ABI bug that recently put some ERC20 funds at risk[1]. Good design principles help prevent problems before they occur.
3) The code can be made more concise. Adopting high-level primitives directly in the language, such as maps and lambdas, make it easier to do what you need with a small program. The language should reflect the type of problems encountered. For instance, building an "updatable" contract in Michelson can be done by putting the contract logic in a lambda and putting that lambda in the contract's storage. It can then be updated according to some logic, such as a multi-signature. Achieving the same thing in Ethereum is much more arduous. You could use a call to an external contract, and have the address of that contract updatable, but you lose all type safety and all isolation.
8 comments
[ 3.1 ms ] story [ 26.1 ms ] threadThe tezos protocal has a major innovation over others: formal governance by the owners of the tokens. It is also proof of stake from the beginning. In general they have made a lot of smart design decisions as documented in their publications going back several years.
They have been slow to launch though. While they might have had a lead on Ether, it is now to be seen how the market reacts to their sale.
If they were old, there would be one, obvious, correct design to follow. However, no one knows precisely what the right formula is yet. This has led to a situation where projects either stagnate -- Bitcoin as network has been unable to integrate important innovations despite the incredible talent of the people working on it -- or build a strong coupling to a central organization, which can threaten their decentralized nature.
How do you design a decentralized protocol that can keep up to date with innovation in this space and yet remain decentralized? That's the problem the governance model is trying to solve.
You mean the innovation that 50% can trivially rewrite history, or something else?
(imo 80% is more than enough to prevent shenanigans -- in most contexts anything even slightly controversial cannot get near 80% support. And in this case, the voting is weighted by stake, and the market value of the Tez would presumably decrease if shenanigans were pulled; Tez-holders would probably be reluctant to do something that is both wrong and also would clearly decrease the value of their holdings. In fact i think the threshold for amendment should be lower than 80%; i might chose 67% if it were up to me)
1) The code can be inspected directly on the blockchain and remain human readable. You can attach Solidity code to an Ethereum contract, but there is no certified compiler yet so you can't be sure they do the same thing.
2) Type safety and an insistence on functional design make good things happen. For instance, by insisting from the get go that contracts should be pure functions, we naturally make it hard to write DAO-like reentrancy bugs. By typing every input, we avoid the ABI bug that recently put some ERC20 funds at risk[1]. Good design principles help prevent problems before they occur.
3) The code can be made more concise. Adopting high-level primitives directly in the language, such as maps and lambdas, make it easier to do what you need with a small program. The language should reflect the type of problems encountered. For instance, building an "updatable" contract in Michelson can be done by putting the contract logic in a lambda and putting that lambda in the contract's storage. It can then be updated according to some logic, such as a multi-signature. Achieving the same thing in Ethereum is much more arduous. You could use a call to an external contract, and have the address of that contract updatable, but you lose all type safety and all isolation.
[1] https://blog.golemproject.net/how-to-find-10m-by-just-readin...