Token Daily Capital Newsletter #3
July 4th, 2019
TWEET OF THE DAY
“Pro tip: Don’t learn anything about core internet protocols. Not even basic concepts. The internet is scary & completely insecure! “
Leigh perfectly summarizes every person’s response when they learn about BGP.
IN BITCOIN
⚡️ Cambridge Bitcoin Electricity Consumption Index
There are plenty of debates around bitcoin that may or may not always be directly related to bitcoin: block size, a monotrophic diet of meat, and a crowd favorite — energy consumption.
To provide more transparency around electricity usage, the Cambridge Center of Alternative Finance launched the Cambridge Bitcoin Electricity Consumption Index to provide an estimate of the Bitcoin network’s energy consumption. The methodology uses parameters like the Bitcoin network hash rate and commercial mining hardware efficiency (Joule/GH) to get a bottom-up estimation of the whole Bitcoin network. At the time of writing, the index shows Bitcoin consumption representing 0.27% of global energy consumption.
The index comparisons section provides interesting comparisons with other countries. The index shows Bitcoin consumes more energy than Switzerland but also shows that it’s still about 25% of the energy consumption of all home devices in the US (if these devices are on but inactive).
Plus, the index provides us with this angle on how many times over the Bitcoin network can be powered by renewables.
IN ETHEREUM
🔹 Freezing the Ethereum 2.0 Phase 0 Spec
The Beacon Chain spec freeze was the most newsworthy event this week. To fully understand what it entails, it’s important to explain how the Ethereum 2.0 phase 0 development process used to work. To make the development process more efficient, the Ethereum Foundation research team (the team responsible for ideating and strategizing on how Ethereum 2.0 will work) and the implementation teams (the teams converting the specifications into working code), e.g., Prysmatic Labs and Lighthouse, have been working in parallel.
While working in parallel is often useful to move faster, it has created some tough situations where implementations teams finish implementing and testing a specific feature only to be surprised that the research team has performed major changes to this feature in the updated spec.
With the spec freeze, this won’t be the case anymore. Dev teams can now focus on making the different Ethereum 2.0 client compatible, launching a multi-client testnet and get the different client implementations audited in preparation for the Phase 0 mainnet launch on Jan 3rd, 2020.
🔹 Straightedge (A 0-day fork of Edgeware lockdrop)
In a comedic backlash to the Edgeware lockdrop rules, Cosmos developer Sunny Aggarwal decided to launch a zero-day fork of the Edgeware protocol calledStraightedge. To illuminate the special treatment Parity gets from Edgeware, the Straightedge token drop will remove the rule that a smart-contract deployer can signal on behalf of the contract (which was a rule that was added last minute to reward Parity for the Polkadot frozen ETH).
To their credit, the Straightedge team (pictured below) looks more legitimate than a lot of projects we’ve seen in the space.
On a more serious note, Sunny’s friendly zero-day fork actually led a researcher to discover a Gridlock bug (now patched) on the Edgeware lockdrop smart-contract code that could have jammed the main lockdrop smart contract (even after an audit was performed on the contract code).
🔹 Privacy on Ethereum
Ethereum developer Kendrick Tan just launched an Ethereum mixer to bring some privacy to Ethereum. His mixer smart-contract, called Heiswap, uses linkable ring signatures and pseduo stealth addresses and is now live on the Ropsten testnet. In order to launch on the Ethereum mainnet, the mixer’s open-source code needs to be audited either by volunteers or by raising funds for an audit (which is usually costly).
READ OF THE DAY
📚The Fall of Certificate Authorities and The Rise of Handshake
Cloudflare suffered two outages this week and took a sizable chunk of the internet down with it. The debacle reignited mainstream debates around centralization as it relates to internet infrastructure. So, we felt it was a good time to dive back into the case for Handshake with a new report on the internet’s reliance on Certificate Authorities, shortcomings of domain validation, how this introduces attack vectors and the case for Handshake.
THOUGHT OF THE DAY
PoS Slashing Conditions: could it force validator centralization?
2019 has been a huge year for PoS networks. Multiple high profile projects that went down the PoS route have already launched on mainnet (Tezos, Cosmos, Algorand, Thundercore) and more are expected to launch before the end of the year or early 2020 (Ethereum 2.0, Dfinity, Polkadot, Avalanche). This trend has led to the proliferation of multiple stalking-as-a-service (STaaS) providers where users can delegate the validation process to professional-grade validators and pay these validators a cut of the validation rewards.
The competition between STaaS providers is already tough. Validators are competing on metrics such as uptime, security, user-friendliness, and their engagement in the PoS network. However, it seems this competition is turning out to be tougher than expected because of PoS slashing conditions.
What could be worse than a validator getting slashed for a technical problem and losing its customers money?
This wasn’t much of an issue until this week. Users always assumed validators had systems in place to avoid major technical problems like prolonged downtimes or, even worse, double signing on proposed blocks. These are severe issues that most of the new PoS consensus mechanisms penalize by slashing the validator security deposit.
The noted assumptions were stress tested last weekend when one of the well-known Cosmos Validators (Cosmospool.org) was slashed due to double signing a proposed block. According to the Tendermint Consensus, 5% of the validator Atoms got slashed and this validator has been permanently jailed (cannot participate in consensus). And these losses are realized by users who delegated to the validator.
Cosmospool delegators’ stakes before slashing
The images above and below compare the stakes of the 3 main delegators to the pool before and after the slashing event which clearly reflect the 5% slashing penalty.
Cosmospool delegators’ stake after slashing
How does this encourage validator centralization?
PoS has been always viewed as an easier way for users to participate in consensus and benefit from network inflation. In contrast to PoW mining, the user doesn’t need to have special mining equipment, whether GPUs or ASIC miners, to participate in consensus. It is enough to hold some coins and delegate these tokens to a validator to get a piece of the validation rewards. At first glance, PoS may seem more decentralized (many more people can contribute to the network consensus). However, with the current complexity and strict requirements on network uptime (especially in delegation based networks), the system may evolve into a few trusted validator brands who control most of the network stake which leads to the creation of centralization points on the network.
While it is possible to argue that the PoW mining pools form similar centralization points, the loss resulting from a mining pool suffering technical issues is less drastic to users than a PoS validator suffering technical issues. In PoW, the loss is limited to the “opportunity cost” or in other words, the loss from missing on mining a number of blocks while the pool was down. In PoS, the losses can be much bigger as the slashing penalty is usually a percentage of the staked tokens. In Cosmos, the slashing percentage was 5% for double signing. In Ethereum 2.0, a double signing slashing penalty is 100% of the validator balance.
Given the higher risk of delegating to a non-top-tier validator, delegators may just focus on delegating to a few trusted brands which could significantly affect a network decentralization.
Being aware of such risks, Ethereum 2.0 researchers opted against baking delegation logic into the Ethereum 2.0 protocol. On Ethereum 2.0 each validator instance should own at least 32 ETH and there is no baked-in mechanism to pool ETH from different “delegators” to act on their behalf. However, this hasn’t stopped Ethereum validation pools like Rocket Pool from forming. Such setups may require trusting the validator entity which could encourage individuals to have their own validating nodes. If this happens, it’ll be an important win for PoS decentralization.
