惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

MongoDB | Blog
MongoDB | Blog
博客园 - 聂微东
Attack and Defense Labs
Attack and Defense Labs
WordPress大学
WordPress大学
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Spread Privacy
Spread Privacy
AI
AI
宝玉的分享
宝玉的分享
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
C
Cyber Attacks, Cyber Crime and Cyber Security
爱范儿
爱范儿
Help Net Security
Help Net Security
V
Visual Studio Blog
大猫的无限游戏
大猫的无限游戏
Forbes - Security
Forbes - Security
P
Privacy & Cybersecurity Law Blog
Project Zero
Project Zero
IT之家
IT之家
Hugging Face - Blog
Hugging Face - Blog
博客园 - 三生石上(FineUI控件)
S
SegmentFault 最新的问题
有赞技术团队
有赞技术团队
T
Troy Hunt's Blog
美团技术团队
T
Threatpost
K
Kaspersky official blog
V
V2EX
Scott Helme
Scott Helme
Vercel News
Vercel News
T
The Blog of Author Tim Ferriss
T
Tailwind CSS Blog
V
Vulnerabilities – Threatpost
Last Week in AI
Last Week in AI
PCI Perspectives
PCI Perspectives
Google Online Security Blog
Google Online Security Blog
Apple Machine Learning Research
Apple Machine Learning Research
Engineering at Meta
Engineering at Meta
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
I
InfoQ
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
酷 壳 – CoolShell
酷 壳 – CoolShell
GbyAI
GbyAI
L
LINUX DO - 最新话题
T
The Exploit Database - CXSecurity.com
L
LangChain Blog
S
Security @ Cisco Blogs
The Last Watchdog
The Last Watchdog
H
Hacker News: Front Page
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
TaoSecurity Blog
TaoSecurity Blog

Ethereum Foundation Blog

Checkpoint #9: Apr 2026 | Ethereum Foundation Blog How L1 and L2s can build the strongest possible Ethereum | Ethereum Foundation Blog The Promise of Ethereum: Introducing the EF Mandate | Ethereum Foundation Blog This Is Fine (Until the Grant Runs Out) | Ethereum Foundation Blog Treasury Staking Initiative | Ethereum Foundation Blog The Ethereum Foundation's Commitment to DeFi | Ethereum Foundation Blog Protocol Priorities Update for 2026 | Ethereum Foundation Blog Announcing the Platform Team at EF | Ethereum Foundation Blog Ethereum Protocol Studies 2026 | Ethereum Foundation Blog Executive Leadership Update | Ethereum Foundation Blog An update from Tomasz | Ethereum Foundation Blog Introducing the EF Academic Secretariat 2026 PhD Fellowship | Ethereum Foundation Blog Trillion Dollar Security Day at Devconnect | Ethereum Foundation Blog Allocation Update - Q4 2025 | Ethereum Foundation Blog Checkpoint #8: Jan 2026 | Ethereum Foundation Blog Devcon 8 is coming to Mumbai, India in November 2026 | Ethereum Foundation Blog Hegota Upgrade EIP Proposal Timelines | Ethereum Foundation Blog Shipping an L1 zkEVM #2: The Security Foundations | Ethereum Foundation Blog The Future of Ethereum’s State | Ethereum Foundation Blog Devconnect Argentina Recap | Ethereum Foundation Blog Allocation Update - Q3 2025 | Ethereum Foundation Blog Making Ethereum Feel Like One Chain Again | Ethereum Foundation Blog Checkpoint #7: Nov 2025 | Ethereum Foundation Blog Fusaka Mainnet Announcement | Ethereum Foundation Blog 2 weeks to Devconnect: Everything you need to know | Ethereum Foundation Blog Unveiling ESP's New Grants Program | Ethereum Foundation Blog Fusaka Update – Transaction Gas Limit Cap arrives with EIP-7825 | Ethereum Foundation Blog Fusaka Update - Information for Blob users | Ethereum Foundation Blog Announcing the 2026 EF Internship | Ethereum Foundation Blog Supporting privacy with new funding mechanisms | Ethereum Foundation Blog The Ethereum Foundation’s Commitment to Privacy | Ethereum Foundation Blog Checkpoint #6: Oct 2025 | Ethereum Foundation Blog Privacy Cluster Leadership Announcement | Ethereum Foundation Blog Fusaka Testnet Announcement | Ethereum Foundation Blog Announcing the districts of the Ethereum World’s Fair | Ethereum Foundation Blog Fusaka $2,000,000 Audit Contest! | Ethereum Foundation Blog Holešky Testnet Shutdown Announcement | Ethereum Foundation Blog The Ecosystem Support Program's Next Chapter | Ethereum Foundation Blog Protocol Update 003 — Improve UX | Ethereum Foundation Blog Protocol Update 002 - Scale Blobs | Ethereum Foundation Blog Trillion Dollar Security - Phase 2 | Ethereum Foundation Blog Join Us: EF Protocol Reddit AMA - August 29th, 2025 | Ethereum Foundation Blog Protocol Update 001 – Scale L1 | Ethereum Foundation Blog lean Ethereum | Ethereum Foundation Blog Celebrating 10 Years of Ethereum | Ethereum Foundation Blog Checkpoint #5: July 2025 | Ethereum Foundation Blog Allocation Update - Q2 2025 | Ethereum Foundation Blog The Future of Ecosystem Development at the EF | Ethereum Foundation Blog Shipping an L1 zkEVM #1: Realtime Proving | Ethereum Foundation Blog Partial history expiry announcement | Ethereum Foundation Blog Checkpoint #4: Berlinterop | Ethereum Foundation Blog World Experience: Updates from the Next Billion Fellowship | Ethereum Foundation Blog Now accepting interns - Join the Ethereum Season of Internships | Ethereum Foundation Blog Tickets are live for the Ethereum World’s Fair! And we're launching the Supporter Program | Ethereum Foundation Blog Ethereum Foundation Treasury Policy | Ethereum Foundation Blog Checkpoint #3: June 2025 | Ethereum Foundation Blog Announcing the Devconnect ARG Scholars Program | Ethereum Foundation Blog Announcing Protocol | Ethereum Foundation Blog Nyota Interop Recap ✨ | Ethereum Foundation Blog Allocation Update - Q1 2024 | Ethereum Foundation Blog Announcing the Ethereum Protocol Fellowship Cohort 5 | Ethereum Foundation Blog Ethereum Protocol Fellowship Cohort 4 Recap | Ethereum Foundation Blog Sepolia Incident | Ethereum Foundation Blog Announcing the Devcon SEA venue! | Ethereum Foundation Blog Devconnect Scholars Program - Ethereum Stories from Istanbul and Beyond | Ethereum Foundation Blog Dencun Mainnet Announcement | Ethereum Foundation Blog ZK Grants Round | Ethereum Foundation Blog Eth2 at ETHWaterloo: Prizes for Eth2 education, tooling, and research | Ethereum Foundation Blog eth2 quick update no. 2 | Ethereum Foundation Blog Devcon4 Ticket Sales | Ethereum Foundation Blog Announcing Swarm Proof-of-Concept Release 3 | Ethereum Foundation Blog Devcon4 Announcement | Ethereum Foundation Blog Announcing May 2018 Cohort of EF Grants | Ethereum Foundation Blog Announcing World Trade Francs: The Official Ethereum Stablecoin | Ethereum Foundation Blog Announcing Beneficiaries of the Ethereum Foundation Grants | Ethereum Foundation Blog Geth 1.8 - Iceberg¹ | Ethereum Foundation Blog Farewell and Welcome | Ethereum Foundation Blog Security Alert - Solidity - Variables can be overwritten in storage | Ethereum Foundation Blog Uncle Rate and Transaction Fee Analysis | Ethereum Foundation Blog Announcement of imminent hard fork for EIP150 gas cost changes | Ethereum Foundation Blog Dev Update: Formal Methods | Ethereum Foundation Blog On Inflation, Transaction Fees and Cryptocurrency Monetary Policy | Ethereum Foundation Blog Onward from the Hard Fork | Ethereum Foundation Blog C++ DEV Update - July edition | Ethereum Foundation Blog The Devcon2 site is now live! | Ethereum Foundation Blog Security Alert - DoS Vulnerability in the Soft Fork | Ethereum Foundation Blog DAO Wars: Your voice on the soft-fork dilemma | Ethereum Foundation Blog Smart Contract Security | Ethereum Foundation Blog Security Alert – Geth suffers from a very low probable DoS attack vector - Update immediately | Ethereum Foundation Blog On Settlement Finality | Ethereum Foundation Blog Ethereum Foundation and Wanxiang Blockchain Labs announce a blockbuster event combining Devcon2 and the 2nd Global Blockchain Summit in Shanghai, September 19–24, 2016 | Ethereum Foundation Blog Ethereum Partners with R3CEV on Lizardcoin, Bringing Together the Best of Centralized Finance and Blockchain Technology | Ethereum Foundation Blog From Smart Contracts to Courts with not so Smart Judges | Ethereum Foundation Blog BTC Relay included in Ethereum Bounty Program | Ethereum Foundation Blog Ethereum DEV Update: C++ Roadmap | Ethereum Foundation Blog Cut and try: building a dream | Ethereum Foundation Blog Ambients Applied to Ethereum | Ethereum Foundation Blog Mihai’s Ethereum Project Update. The First Year. | Ethereum Foundation Blog Getting to the Frontier | Ethereum Foundation Blog The Ethereum Development Process | Ethereum Foundation Blog
Slasher: A Punitive Proof-of-Stake Algorithm | Ethereum Foundation Blog
2014-01-15 · via Ethereum Foundation Blog

The purpose of this post is not to say that Ethereum will be using Slasher in place of Dagger as its main mining function. Rather, Slasher is a useful construct to have in our war chest in case proof of stake mining becomes substantially more popular or a compelling reason is provided to switch. Slasher may also benefit other cryptocurrencies that wish to exist independently of Ethereum. Special thanks to tacotime for some inspiration, and for Jack Walker for improvement suggestions.

Proof of stake mining has for a long time been a large area of interest to the cryptocurrency community. The first proof-of-stake based coin, PPCoin, was releasd by Sunny King in 2012, and has consistently remained among the top five alternative currencies by monetary base since then. And for good reason; proof of stake has a number of advantages over proof of work as a mining method. First of all, proof of stake is much more environmentally friendly; while proof of work requires miners to effectively burn computational power on useless calculations to secure the network, proof of stake effectively simulates the burning, so no real-world energy or resources are ever actually wasted. Second, there are centralization concerns. With proof of work, mining has been essentially dominated by specialized hardware (“application-specific integrated circuits” / ASICs), and there is a large risk that a single large player such as Intel or a major bank will take over and de-facto monopolize the market. Memory-hard mining algorithms like Scrypt and now Dagger mitigate this to a large extent, but even still not perfectly. Once again, proof of stake, if it can be made to work, is essentially a perfect solution.

However, proof of stake, as implemented in nearly every currency so far, has one fundamental flaw: as one prominent Bitcoin developer put it, “there’s nothing at stake”. The meaning of the statement becomes clear when we attempt to analyze what exactly is going on in the event of an attempted 51% attack, the situation that any kind of proof-of-work like mechanism is intended to prevent. In a 51% attack, an attacker A sends a transaction from A to B, waits for the transaction to be confirmed in block K1 (with parent K), collects a product from B, and then immediately creates another block K2 on top of K – with a transaction sending the same bitcoins but this time from A to A. At that point, there are two blockchains, one from block K1 and another from block K2. If B can add blocks on top of K2 faster than the entire legitimate network can create blocks on top of K1, the K2 blockchain will win – and it will be as if the payment from A to B had never happened. The point of proof of work is to make it take a certain amount of computational power to create a block, so that in order for K2 to outrace K1 B would have to have more computational power than the entire legitimate network combined.

In the case of proof of stake, it doesn’t take computational power to create a work – instead, it takes money. In PPCoin, every “coin” has a chance per second of becoming the lucky coin that has the right to create a new valid block, so the more coins you have the faster you can create new blocks in the long run. Thus, a successful 51% attack, in theory, requires not having more computing power than the legitimate network, but more money than the legitimate network. But here we see the difference between proof of work and proof of stake: in proof of work, a miner can only mine on one fork at a time, so the legitimate network will support the legitimate blockchain and not an attacker’s blockchain. In proof of stake, however, as soon as a fork happens miners will have money in both forks at the same time, and so miners will be able to mine on both forks. In fact, if there is even the slightest chance that the attack will succeed, miners have the incentive to mine on both. If a miner has a large number of coins, the miner will want to oppose attacks to preserve the value of their own coins; in an ecosystem with small miners, however, network security potentially falls apart in a classic public goods problem as no single miner has substantial impact on the result and so every miner will act purely “selfishly”.

The Solution

Some have theorized that the above argument is a deathblow to all proof of stake, at least without a proof of work component assisting it. And in a context where every chain is only aware of itself, this is indeed provably true. However, there is actually one clever way to get around the issue, and one which has so far been underexplored: make the chain aware of other chains. Then, if a miner is caught mining on two chains at the same time, that miner can be penalized. However, it is not at all obvious how to do this with a PPCoin-like design. The reason is this: mining is a random process. That is to say, a miner with 0.1% of the stake has a 0.1% chance of mining a valid block on block K1, and a 0.1% chance of mining a valid block on block K2, but only a 0.0001% chance of mining a valid block on both. And in that case, the miner can simply hold back the second block – because mining is probabilistic, the miner can still gain 99.9% of the benefit of mining on the second chain.

The following proposal, however, outlines an algorithm, which we are calling Slasher to express its harshly punitive nature, for avoiding this proposal. The design description given here uses address balances for clarity, but can easily be used to work with “unspent transaction outputs”, or any other similar abstraction that other currencies may use.

  1. Blocks are mined with proof of work. However, we make one modification. When creating a block K, a miner must include the value H(n) for some random n generated by the miner. The miner must claim the reward by releasing a transaction uncovering n between block K+100 and K+900. The proof of work reward is very low, ideally encouraging energy usage equal to about 1% of that of Bitcoin. The target block time is 30 seconds.
  2. Suppose the total money supply is M, and n[i] is the n value at block i. At block K+1000, an address A with balance B gains a “signing privilege” if sha256(n[K] + n[K+1] + ... + n[K+99] + A) < 2^256 * 64 * B / M. Essentially, an address has a chance of gaining a signing privilege proportional to the amount of money that it has, and on average 64 signing privileges will be assigned each block.
  3. At block K+2000, miners with signing privileges from block K have the opportunity to sign the block. The number of signatures is what determines the total length of one blockchain versus another. A signature awards the signer a reward that is substantially larger than the proof of work reward, and this reward will unlock by block K+3000.
  4. Suppose that a user detects two signatures made by address A on two distinct blocks with height K+2000. That node can then publish a transaction containing those two signatures, and if that transaction is included before block K+3000 it destroys the reward for that signature and sends 33% to the user that ratted the cheater out.

The key to this design is how the signing privileges are distributed: instead of the signing privilege being randomly based on the previous block, the signing privilege is based on the block two thousand blocks ago. Thus, in the event of a fork, a miner that gets lucky in one chain will also get lucky in the other, completely eliminating the probabilistic dual-mining attack that is possible with PPCoin. Another way of looking at it is that because Slasher uses proof-of-stake-2000-blocks-ago instead of proof-of-stake now, and forks will almost certainly not last 2000 blocks, there is only one currency supply to mine with, so there is indeed “something at stake”. The penalty of block reward loss ensures that every node will take care to sign only one block at each block number.

The use of 100 pre-committed random numbers is an idea taken from provably fair gambling protocols; the idea is that powerful miners have no way of attempting to create many blocks and publishing only those that assign their own stake a signing privilege, since they do not know what any of the other random data used to determine the stakeholder is when they create their blocks.

The system is not purely proof-of-stake; some minimal proof-of-work will be required to maintain a time interval between blocks. However, a 51% attack on the proof of work would be essentially inconsequential, as proof of stake signing is the sole deciding factor in which blockchain wins. Furthermore, the energy usage from proof of work can be made to be 95-99% lower, resolving the environmental concern with proof of work.