,
36 tweets,
16 min read
Read on Twitter
PART TWO
22/ Here I focus on an exploration of common attack vectors inherent in blockchains, & what solution(s) can combat them (to the best of my knowledge). Will use project-specific examples to keep this as tangible as possible.
For a recap of Part One, see below👇
22/ Here I focus on an exploration of common attack vectors inherent in blockchains, & what solution(s) can combat them (to the best of my knowledge). Will use project-specific examples to keep this as tangible as possible.
For a recap of Part One, see below👇
23/ Some people have asked about hybrid PoW/PoS - I'm going to hold off on that for this Part Two to stay on course, but will touch on this in an appendix after Part Three.
24/ First up: Sybil attack. This seems to be tossed around pretty loosely on #cryptotwitter. This is a type of attack seen in p2p networks in which a node in a network operates multiple identities actively at once & undermines/subverts the authority/power in reputation systems.
25/ At quick glance it's easy to think that Sybil attacks aren't an issue with PoS systems. After all, staking is inherently something that takes 'stake' (e.g., skin in the game), which is what should prevent a Sybil possibility in the first place.
26/ Assuming proper design, this may be, but in the absence of a cost of staking or reputation system, Sybil attacks can surely occur. There is not necessarily always an external cost to staking (e.g., borrowing, forks, delegation).
27/ Many view staking off a basis of an inherently limited resource, where as long as weight is proportional to that resource, it doesn't matter if you split it across a bunch of Sybils or have it in one entity.
28/ This isn't always the case (weight proportional to resource). For instance, EOS doesn't have this. Block producers are elected by token holders, so Sybil attacks are combatted via a reputation system - they can be voted out if they are seen to be malicious in any way.
29/ To wrap that up, Sybil attacks can be combatted via (external) cost to stake or a reputation system. Some popular projects implementing the cost methods are Eth2.0, @meetCasperLabs, @SolanaLabs, @tezos, @dfinity, @NEARProtocol, @OasisLabs, @ThunderProtocol, @polkadotnetwork.
30/ Some projects implementing the reputation method are @EOS_io, @cosmos, @tendermint_team & @terra_money.
31/ Next up we have the distributed denial of service (DDoS) attack. This is a cyber attack in which a perpetrator seeks to make a network resource unavailable to its intended users by temporarily or indefinitely disrupting services.
32/ As I understand it, several methods can combat this starting with introducing unbiasable randomness (entropy) to the consensus election process. This takes the form of a verifiable random function (VRF). Bear with me... I know this is getting dense!
33/ In simplest terms, randomness serves as a defense mechanism against front-running the election process in distributed consensus. There are 3 common approaches to constructing VRFs:
1) a verifiable delay function (VDF)
2) a commit-reveal scheme
3) BLS signatures
1) a verifiable delay function (VDF)
2) a commit-reveal scheme
3) BLS signatures
34/ A verifiable delay function (VDF) is a function that enables a time delay imposed on the output of some pseudo-random generator. VDFs are extremely computationally expensive functions that cannot be parallelized (an attractive security feature).
eprint.iacr.org/2018/601.pdf
eprint.iacr.org/2018/601.pdf
35/ The delay prevents malicious actors from influencing the output of the pseudo-random generator, since all inputs will be finalized before anyone can finish computing the VDF. Ethereum 2.0, @meetCasperLabs, @SolanaLabs, & @tezos are some popular PoS projects using VRFs + VDFs.
36/ In a commit-reveal scheme, a validator commits to a chosen value while keeping it hidden from others, and then reveals the committed value later after hashing. These schemes are designed so committed values cannot be changed & randomness cannot be manipulated.
37/ @Algorand & Ouroboros Genesis consensus (@CodaProtocol, @Cardano) are PoS networks using VRF + commit-reveal.
38/ BLS Signatures. These are a form of threshold signatures whereby bilinear pairing (e.g., defined M of N multisig) is used for verification.
medium.com/cryptoadvance/…
medium.com/cryptoadvance/…
39/ @RongjianLan does a great job discussing VRFs with additional specific project examples for those interested in going deeper on the topic (I'm trying to stay as high-level here as possible):
talk.harmony.one/t/unbiasable-r…
talk.harmony.one/t/unbiasable-r…
40/ That was a lot. Let's digest. Randomness helps combat DDoS vulnerabilities b/c it challenges the ability for a perpetrator to front-run the election process in distributed consensus. We discussed a verifiable random function & three common approaches to construct it.
41/ Another way to potentially combat against DDoS vulnerabilities is to have an identifiable, fixed committee of validators that are old-fashioned trusted as each one injects security deposit-based collateral into a network that can be slashed in the event of malicious behavior.
42/ @cosmos, @tendermint_team, @EOS_io, @NEARProtocol, @ThunderProtocol, @polkadotnetwork & @terra_money are some examples of popular PoS projects that to the best of my knowledge implement fixed committees with security deposit-based collateral.
43/ The last two common attacks I'll cover here are stake grinding & range-bound nothing-at-stake attacks. Stake-grinding is an attack in which an attacker manipulates the blockchain in a way to maximize the probability of being elected as the leader for the ensuing block(s).
44/ An obv example of a stake grinding attack is when an attacker has a small amount of stake & goes through a blockchain's history to find places where his/her stake wins a block. In order to consecutively win, the attacker modifies the next block header until he/she wins again.
45/ Stake grinding can generally be combatted *somewhat* similarly to how DDoS is combatted, with unbiased randomness implemented in the election process or fixed committees that have injected security deposit-based collateral.
46/ Lastly, nothing-at-stake attacks are ones in which a validator in a committee votes (without penalty) for two blocks at the same block height. Simply put, the nothing-at-stake problem allows someone to misbehave - and get away with it.
47/ There are generally 2 ways to combat nothing-at-stake attacks: 1) bond deposits (e.g., security deposit-based collateral that can be slashed in the event of malicious action), or 2) a fork-choice rule. This goes back to liveness vs. safety:
48/ Slashing is pretty straightforward – if one behaves badly, he/she is financially penalized. This is common with networks that favor safety over liveness (e.g., @cosmos, @tendermint_team, @EOS_io, @nearprotocol, @oasislabs, @polkadotnetwork, @tezos & @terra_money).
49/ Fork-choice rules are generally more complex & are inherent in networks favoring liveness over safety. Some popular PoS projects favoring liveness are: ETH2.0, @meetCasperlabs, @SolanaLabs, @Algorand, @dfinity, @thunderprotocol & Ouroboros Genesis (@CodaProtocol, @Cardano).
50/ To understand the premise behind the fork-choice rule, recall that in PoW networks, the probability of miners winning the next block is proportional to the percentage of total hashpower contributed.
51/ #Bitcoin combines fork-choice rule w/ the req. that miners produce proofs of work (solving algorith. complex math puzzle), which are costly to generate b/c each miner has limited (expensive to acquire) hashpower & anything improperly spent on the wrong chain is wasted.
52/ This is why, in the event of network partitions (forks), little value is justified for minority chains by the market (the market makes a choice), as we have evidently seen (bitcoin vs. bitcoin cash is a famous example).
53/ We’ve now covered ways to combat Sybil attacks, DDoS attacks, stake grinding attacks, nothing-at-stake attacks & network partitions, 5 commonly known attacks in blockchain land. You should notice, with the except. of bitcoin in #51, all examples used were PoS. Why was that?
54/ It’s simple. This is an effort to explore if a line can be drawn between “extremely secure” & “secure enough”. Can PoS networks be *secure enough* (vs. PoW) to still capture billions, if not trillions, in value depending on the use case?
55/ Others like @spencernoon & @ariannasimpson are already questioning if security premiums can develop irrespective of monetary premiums. I’d love to see more work done here, though time will likely play a major factor in the ability to have an answer.
56/ In my next & final part I will recap the key takeaways from this exercise & examine them in the context of a risk/reward framework. I’ll also include a brief appendix afterward that touches on hybrid PoW/PoS given some people have asked for it. Stay tuned!
