-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path34159731.deep-dive-into-scaling-part-1.html
1 lines (1 loc) · 8.9 KB
/
34159731.deep-dive-into-scaling-part-1.html
1
<h1>Proof of stake - Security</h1><p>Proof of stake is socially-coordinated majority rule. One dollar, one vote. A majority of token holders in the system in the current state decide future states of the system. This majority is responsible for setting rules and ensuring they are followed. Rules include:</p><ul><li><p>Only signed transactions are accepted</p></li><li><p>Minting and burning of token happens as per some rules</p></li><li><p>Contracts run code as per some rules</p></li><li><p>Attempts at breaking rules are penalised as per some slashing rules</p></li></ul><p>The majority has the authority to change these rules at any point, and even apply these changes retroactively. The majority can, for instance, move assets from one account to another (even without a signature), or slash anyone’s assets at any point. Technically, the majority can defraud a minority and get away with it.</p><p></p><p>This does not happen in practice because the value of the assets being coordinated upon depends on faith in the coordination mechanism itself. ETH holds value only as long as people give it value (whether as a store of value or as an equity). If a minority does not approve of the rules, they will stop using the system or holding the native token (ETH). ETH price will decline. The minority can also respond by creating a fork of their own, presumably one where they have slashed the offending majority. Unlike proof of work, minority forks can peacefully co-exist with majority ones.</p><p>Forking is negative sum for all parties due to network effects being lost (people on one fork can’t transact with people on the other). This is akin to a civil war and a country splitting in two. Bigger, united countries are always better due to more coordination of resources taking place, as long as the governance mechanism can handle it and all citizens can agree on common rules.</p><p></p><h1>Proof of stake - Scaling</h1><p>You ideally want as many users as possible to participate in governance of a proof of stake system. The ideal is to have every user participate (like in a democratic government). This means running a node or validator. Running a node checks what the rules are and whether they are being followed. Only if you know what the current rules are can you contribute into the discussion for how these rules can be changed. Running a node has both an upfront cost (storage, processor, internet setup) and a smaller running cost (electricity, bandwidth, compute power). If you want everyone to participate (know what rules are being followed or help change them), you want to minimise node running costs. This places a limit on transactions per second, and state growth (how much storage is needed to store current state).</p><p></p><p>Transacting on proof of stake is like a democratic government (technically plutocratic) voting on every single transaction that takes place. Unlike modern democracies which are representative, this is direct. In fact it is hyper-direct as you get transaction-level granularity - people vote on individual transactions. Clearly such a system doesn’t scale. </p><p>A transactor pays costs both in the form of transaction fees and node running costs. Clearly a transactor will only pay this if the “economic value” he gets from transacting somehow exceeds this cost. For instance if you pay $1 to move $1,000 around it means you are somehow deriving $1 of value from being able to move $1,000 on this pseudonymous permissionless network. These fees are used incentivise validators, who incur a slightly higher running cost (and risks) as compared to vanilla node runners.</p><p></p><p>Some transactors will derive a lot of value from using this system, they can afford to spend much more on running a node. The problem with such a system is that the people who cannot afford these higher costs are excluded from the system. Therefore it makes sense to minimise cost on the base layer and increase it on higher layers.</p><p></p><p>As it stands, many users already do not run their own nodes, they trust Infura (Metamask) or Etherscan to run it for them. Infura or Etherscan effectively becomes a media channel, providing the ultimate source of truth, which you can either accept at face value or verify for some cost. They stake their reputation and might provide some paid value-add serviced, which they stand to lose if they are malicious. Again, quite like a media channel.</p><p></p><h1>Sidechains - Security</h1><p>A sidechain is just a blockchain with higher node running costs. A subset of users on the main ethereum blockchain who derive high value and can afford to run more expensive nodes can use a sidechain.</p><p>A sidechain is of two types - either it uses base layer assets like ETH, or it doesn’t.</p><ol><li><p>A sidechain could transact ETH or any base layer asset like DAI. The problem with this is that ETH’s value comes ethereum’s social coordination whereas the sidechain’s security comes from people staking in the sidechain. This means value and coordination over rules are disconnected. This gives incentive for the majority to simply rob the minority. Unlike in a simple blockchain, the assets the majority has robbed (ETH) will not drop in value after they are stolen.</p></li><li><p>A sidechain can use a native asset instead and completely isolate itself from the ethereum blockchain. It is just another blockchain at this point. This allows for social coordination. The asset will drop in value if a minority feels defrauded, forks can occur and so on. The problem, ofcourse, is that you can no longer use any assets from the base layer. You will also get an increasing number of users who trust someone else to run a node for them, if this system is the primary one available.</p></li></ol><p></p><h1>Multichain - Security</h1><p>Each chain is secure as already discussed. For instance BTC and ETH both co-exist and both are secure in that they follow the rules set by their majority of holders respectively,</p><p></p><h1>Multichain - Scaling</h1><p>Multichain is not a good scaling solution. If the chains are isolated, you lose network effects, and can only transact with other wealth also present on that chain.</p><p>If you use bridged assets (say WBTC on Ethereum), then you are not only trusting both chains to remain secure, you are also trusting the bridge to remain secure - the bridge likely has weaker security properties than both the chains it is bridging. At best, the bridge can be a blockchain of its own - in which case you might as well just use that blockchain directly.</p><p></p><h1>State channel - Security</h1><p>A state channel is a solution where n parties pool assets in a contract, and then sign off-chain transactions as to what is to happen with those assets. Usually n = 2. A transaction is valid only if all parties have signed it. This means that all parties need to be online when a transaction has to take place.</p><p>This is like a bunch of people signing contracts that allow assets to be moves only if <em>all parties agree</em>. If at any point somebody doesn’t agree something should happen, they go to the base layer blockchain - this is like going to court, except the court is not run by a representative (judge), it is run by a hyper-direct plutocratic vote of every single person in the country. All users submitted the latest state that was signed by all parties. All states are numbered (by a nonce) - the one with highest nonce is accepted as latest.</p><p>Members of a state channel can use their own smart contracts too. If someone raises a dispute, then the contracts need to be actually deployed on the base layer and execution will have to continue from there instead. The contract could include a termination clause so it easy for the person disputing to be paid a fair compensation on-chain. Remaining members can then open a new state channel instead of doing all the work on-chain.</p><p></p><h1>State channels - Scaling</h1><p>State channels are a great scaling solution for a small set of parties that can remain online and frequently need to transact with each other. This could be shareholders of a company or DAO, or clearing houses for banks. The liveness requirement can be reduced by placing a challenge period - the contract controlling the assets will only close X hours or days after a dispute is raised, this gives other parties enough time to come and raise them. The down-side ofcourse is that someone can fraudulently make everyone wait - this is like a nuisance suit. Also this doesn’t work great for more than two parties. If A and B wish to transact but C is offline, they cannot transact. </p><p></p><p>A dispute also forces people to go back to the base layer and incur gas costs - therefore a state channel is only worth entering if the value you expect to obtain before a dispute happens is more than this cost. Users can also stake bonds, which are slashed or distributed if they lose a dispute. This is like a court case demanding the losing party to pay for the litigation costs incurred by the winning party.</p>