Author: Polynya
I realized that I never really tackled the question of how to build an effective security layer. One thing to clarify here is that I'm only talking about security and authentication, not data availability. Rather, I'm talking about a proven and resilient decentralized strong security layer on which rollups, volitions, and validations (and future innovations in the execution layer) run. The main reason I haven't talked about this is that it's a lackluster space, with only two projects currently focusing on it - all the other chains sacrifice security and decentralization to varying degrees for ease of execution. This article is highly subjective, as security and decentralization are difficult to quantify. In this article, I'll try to quantify them and rank them in order of importance.
User Self-Authentication Culture
(I think compared to other points mentioned in this article) the most important point is that end users, developers, wallets, exchanges, infrastructure providers and other participants in the ecosystem run non-validating ) full node culture. (Translator's Note: The non-validating here refers to not participating in block production. Because the full node will definitely verify the validity of the block, otherwise it is not a full node. The reason for this confusion is that some PoS algorithms In the expression, those who participate in block production are also called "verifiers", so the relationship between verbs and nouns is lost: those who have done verification work are not necessarily "verifiers". Readers will also encounter this kind of confused.)
There are many ways to do this:
First, keep overhead within limits - put ease of running a node over scalability.
An efficient client that can better sync and store data.
Cryptographic solutions such as statelessness and state validity.
Currently, Bitcoin remains the easiest mainstream network to verify — anyone can run a Bitcoin node on a laptop. In contrast, the threshold for Ethereum is much higher, although some smart hardware configurations can be supported (mainly requiring solid-state drives). The culture of user self-verification is not dead. Statelessness and state validity are the two primary tasks at present, which can effectively reduce the difficulty of running Ethereum nodes. In the short term, after the merger of Eth1 and Eth2, we will have efficient light clients. I only know of these two projects that focus on security and decentralization.
I'll explain why this is so important later on. Be aware that a network is not permission-free if it does not allow users to run their own nodes. You are simply replacing governments and bankers with a limited set of validators.
Wide Token Distribution
Especially for proof-of-stake networks, a wide distribution of tokens is critical. Currently, I don't think there is a single network whose token distribution is sufficiently decentralized, although Bitcoin and Ethereum are far ahead, and Litecoin is a distant third. Ridiculously, some new projects are still centralized, such as Solana and Avalanche - I think it is better to trust a reputable bank. One could argue that these projects will eventually become decentralized, but there is no practical way to achieve decentralization. Decentralization is at odds with the delegated consensus mechanism they employ (revenue through staking). The greater the number and types of participants on a global scale, the more resilient the network will be.
In the long run, as Ethereum turns to the PoS mechanism, Bitcoin's mechanism will become the most decentralized mechanism.
A culture of user self-verification and broad token distribution are two of the most critical elements of the security layer. There are a few other elements, although not so critical, but they are also very important:
economic security
As Justin Drake argues in his must-read trilogy on Bankless, economic security is quantifiable, but trickier than it first appears. We can define economic security as the cost of attacking a network. In the case of a proof-of-work network, economic security is the cost of obtaining 51% of the computing power. These computing power can be obtained by leasing and acquiring ASICs. We can estimate the cost of the attack by taking the price of rented computing power and multiplying it by 51% of the computing power. Although this is only a hypothetical estimate, according to data from crypto51.app, the economic security of Ethereum ranks first, Bitcoin ranks second, and other networks are far behind. Of course, it is impractical to achieve 51% computing power, and the actual cost is difficult to calculate. In the case of Proof of Stake, the calculations can be complicated due to the many differences between the consensus mechanisms.
Secure Consensus Mechanism
While it might be controversial to say this, I think the consensus mechanism is the least important to the security of a chain. In contrast, user self-verification and wide token distribution are far more important. If these two criteria are not met, the nuances between consensus mechanisms simply won't matter.
This is because validators serve the network — the consensus rules are enforced by users running nodes. If you have a large number of users participating in the verification, it will act as a deterrent to the validator. Even in the event of an attack, the network will not crash or be completely destroyed.
However, the differences between consensus mechanisms do matter. For example, networks such as Ethereum and Algorand use a non-delegating consensus mechanism that is superior to a delegated consensus mechanism (electing validators in a plutocratic regime). The latter is a dystopian view that the security of the network is determined by "whales" and that other stakeholders don't care about it - they just want ) to get a share. Of course, this is not a big deal if the token distribution is sufficiently decentralized - again highlighting the importance of having a widely distributed token. Of course, one could argue that even delegation pools built on "true" Proof-of-Stake without delegation have advantages. For example, the automated and randomized systems of Rocket Pool and SSV can completely circumvent attack vectors such as bribery introduced by plutocratic political elections and delegation mechanisms. Finally, it is especially important to be able to run validator nodes without delegating to or seeking permission from whales.
There are many other nuances to consider here, e.g. typical BFT delegated consensus mechanism cannot defend against 33% attack, beacon chain and proof-of-work chain can resist up to 50% attack; Can the network recover better from most attacks; whether group leader election is private; whether determinism can be achieved quickly, etc. Finally there is the power of the community in social coordination and recovery from fringe scenarios such as a successful attack.
Having spent all this time, the core point I want to make is this - there are many small differences between consensus mechanisms, but these differences are not that important. Even a substandard delegated consensus mechanism with only 1000 validators is acceptable if there are millions of users validating and 1 billion token holders. (Translator's Note: Once again, readers can feel the harm caused by the mixed terms: the "verification" in the previous "millions of users participating in the verification" refers to running a full node to verify the integrity of the block; the latter " 1000 validators" refers to the protocol's block producers.)
There are two other points that are equally important, but do not fit the above mechanism.
Lindy effect and network effect, decentralized development, ecological support
For a secure chain, a proven elastic network, a high token premium, and tens of thousands of developers participating in the construction are ideal features. To reiterate, Bitcoin is number one, but Ethereum is catching up. Ethereum is far ahead in developer adoption and multi-client development. A multi-client network is far more resilient than a single-client network where only one development team is building a single client. Of course, one could argue that instead of distributing human resources to multiple clients, they should all be devoted to building one perfect client.
Is it ZKP friendly
If you think about what I have discussed in this article, you will come to this conclusion: the blockchain industry has only two secure chains that can compete with each other - Bitcoin and Ethereum. Sadly, Bitcoin is incapable of one thing: it doesn't have the ability to verify ZKPs (Zero-Knowledge Proofs). No one even mentions this, but I think it's a no-brainer to introduce this feature, and it's the most impactful upgrade Bitcoin can make, way ahead of Taproot.
Ethereum is indeed able to verify zk-SN(T)ARK. EIP 1679 certainly helps, but the EVM is still very unfriendly to ZKP verification. Now, I don't have enough knowledge of ZKP cryptography to understand the details, but some precompilation can make it easier for zkR, validium, and volition to settle on Ethereum - especially STARK. Fortunately, executive layer developers such as Matter Labs, Aztec, and StarkWare have demonstrated a talent for innovating to circumvent the limitations of the EVM. However, there is room for improvement to maximize distance efficiency. I hope that core researchers and developers will implement relevant precompilation and opcode after the merger of Eth1 and Eth2 is completed, because Ethereum's dependence on rollup is getting stronger and stronger. Of course, I know that the EVM is somewhat rigid, making it difficult to implement major changes - I have an inspiration to build a virtual machine shard chain from scratch, dedicated to validating ZKP, or make this function into the beacon chain. (Although realistically, the development of the executive layer is now focused on (beacon chain stakers) withdrawals, (PoW-PoS) post-merge cleanup, and statelessness.)
Bonus: massive data availability layer
in conclusion
in conclusion
Original link:
Original link:
https://polynya.medium.com/security-layers-or-qualifying-security-decentralization-7a5c93a36ba3
