The Rise of Slasher Ghost: Innovative Evolution in Proof of Stake Systems

Sincere appreciation to Vlad Zamfir and Zack Hess for their continued research and dialogues regarding proof-of-stake algorithms and their unique contributions to Slasher-like suggestions

One of the most challenging issues in cryptocurrency development is the creation of effective consensus mechanisms. Undoubtedly, some reasonably effective default alternatives are available. At a minimum, it is feasible to depend on a Bitcoin-esque proof of work mechanism based on either a randomized circuit strategy designed for specialized hardware resistance, or if that fails, a straightforward SHA3, and our current GHOST optimizations enable such a mechanism to achieve block intervals of 12 seconds. Nonetheless, proof of work as a broad category presents numerous shortcomings that raise doubts about its viability as a sole source of consensus; 51% attacks from altcoin miners, impending ASIC supremacy, and significant energy inefficiency are perhaps the most notable. In recent months, we have grown increasingly persuaded that incorporating some form of proof of stake is essential for enduring viability; however, executing an effective proof of stake mechanism is emerging as unexpectedly complex.

The inclusion of a Turing-complete contract system in Ethereum complicates matters further, as it simplifies certain types of collusion without necessitating trust, and creates a significant pool of stake in the hands of decentralized entities that are incentivized to vote with their stake for rewards, yet lack the cognitive ability to distinguish between good and bad blockchains. The remainder of this article will present a collection of strategies that address most challenges associated with current proof of stake mechanisms, and provide a preliminary outline for enhancing our preferred proof-of-stake algorithm, Slasher, into something considerably more resilient.

Historical Overview: Proof of stake and Slasher

If you are not yet familiar with the intricacies of proof of stake mechanisms, please first read: https://blog.ethereum.org/2014/07/05/stake/

The primary challenge that consensus protocols aim to resolve is establishing a method for expanding a blockchain over time in a decentralized manner that cannot be easily compromised by attackers. If a blockchain does not utilize a consensus protocol to manage block production and permits anyone to append a block at any moment, then an attacker or botnet with numerous IP addresses could inundate the network with blocks, and specifically, they can exploit this power to execute double-spend attacks – issuing a payment for a product, waiting for the transaction to be confirmed in the blockchain, and subsequently initiating their own “fork” of the blockchain, replacing the earlier payment with a payment to a different account under their control, and lengthening it beyond the original so that everyone acknowledges this new blockchain sans the payment as valid.

The overarching solution to this issue involves making the creation of a block “difficult” in some manner. In the context of proof of work, each block necessitates computational effort to generate, while in proof of stake it requires possession of coins – in most instances, it is a probabilistic process where block-creation privileges are randomly distributed in proportion to coin ownership, and in more unconventional “negative block reward” systems, anyone can generate a block by expending a certain amount of funds, and they receive compensation through transaction fees. In any of these models, each chain possesses a “score” that fairly reflects the cumulative difficulty of generating the chain, and the chain with the highest score is acknowledged as the “truth” at that specific moment.

For an in-depth examination of some of the subtleties of proof of stake, refer to the linked article above; for those who are already knowledgeable about the concerns, I will commence by introducing a semi-formal specification for Slasher:

1. Blocks are generated by miners; for a block to be deemed valid, it must fulfill a proof-of-work criterion. However, this requirement is relatively lenient (e.g., we can set the mining reward to approximately 0.02x the genesis supply annually)
2. Each block has a set of designated signers, which are pre-selected (see below). For a block with valid PoW to be integrated into the chain, it must be accompanied by signatures from at least two-thirds of its designated signers.
3. When block N is generated, we state that the set of potential signers of block N + 3000 is composed of addresses such that sha3(address + block[N].hash) where D2 is a difficulty parameter aimed at 15 signers per block (i.e., if block N has less than 15 signers it decreases, otherwise, it increases). It is important to note that fully enumerating the potential signers’ set is highly computationally intensive, and we do not attempt to do so; instead, we rely on signers to self-identify.
4. If a potential signer for block N + 3000 wishes to become a designated signer for that block, they must transmit a specific transaction accepting this duty, and this transaction must be included between blocks N + 1 and N + 64. The group of designated signers for block N + 3000 consists of all individuals who undertake this action. This “signer must confirm” mechanism aids in ensuring that the majority of signers will indeed be online when the time comes to sign. For blocks 0 … 2999, the pool of signers is vacant, hence proof of work alone suffices to produce those blocks.
5. When a designated signer appends their signature to block N + 3000, they are set to obtain a reward in block N + 6000.
6. If a signer endorses two distinct blocks at height N + 3000, then if someone identifies the double-signing before block N + 6000 they are able to present an “evidence” transaction featuring the two signatures, nullifying the signer’s reward and reallocating a third of it to the informant.
7. If there is a lack of adequate signers to endorse at a certain block height h, a miner can generate a block with height h+1 directly atop the block with height h-1 by mining at 8 times the original difficulty (to motivate this, but still make it less appealing than creating a standard block, there is a 6 times greater reward). Bypassing two blocks results in higher difficulties of 16x and rewards of 12x, and for three blocks, it becomes 32x and 24x, and so forth.

Fundamentally, by overtly penalizing double-signing, Slasher in numerous ways, though not all, makes proof of stake behave somewhat like a form of simulated proof of work. A significant incidental advantage of Slasher is its non-reversion property. In proof of work, sometimes once a node successfully mines a block, another node will immediately mine two blocks which requires some nodes to revert back one block when they observe the longer chain. Conversely, here, every block necessitates two-thirds of the signers to approve it, and a signer cannot approve two blocks at the same height without forfeiting their rewards in both chains, therefore assuming no misconduct, there will be no reversion in the blockchain. From the perspective of a decentralized application developer, this property is extremely valuable as it indicates that “time” only proceeds in a single direction, just as it does in a server-based environment.

Nonetheless, Slasher remains susceptible to a specific category of attack: long-range attacks. Rather than attempting to initiate a fork from ten blocks behind the current head, suppose an adversary aims to initiate a fork beginning from ten thousand blocks behind, or even the genesis block – the crucial factor is that the depth of the fork must exceed the duration of the reward lockup. At that juncture, since users’ funds become accessible and they can transfer them to a new address to avoid penalties, users lack any disincentives against signing on both chains. In fact, we might expect to witness a clandestine market of individuals selling their aged private keys, culminating in an attacker independently obtaining access to the keys governing over 50% of the currency supply at some historical point.

One solution to the long-range double-signing dilemma involves transactions-as-proof-of-stake, an alternative PoS approach that lacks an incentive to double-sign as the transactions cast votes, with no rewards for sending a transaction (in fact, it incurs a cost, and the reward lies outside the network); however, this does nothing to mitigate the black key market issue. To adequately address that concern, we must loosen a hidden assumption.

Subjective Scoring and Trust

Despite its drawbacks, proof of work does possess some refined economic attributes. Notably, since proof of work demands an external rivalrous resource, something that exists and is used outside the blockchain, to generate blocks (specifically, computational effort), launching a fork against a proof of work chain necessitates access to, and the expenditure of, a substantial amount of economic resources. In contrast, in proof of stake, the only scarce value at stake is value within the chain, and between multiple chains that value is not at all scarce. Regardless of the algorithm utilized, in proof of stake, 51% of the owners of the genesis block could eventually unite, collude, and create a longer (i.e., higher-scoring) chain than all others.

This may seem a critical shortcoming, but in reality, it is only a flaw if we implicitly accept an assumption relevant to proof of work: that nodes possess no knowledge of historical events. In a proof-of-work protocol, a new node, lacking direct awareness of past occurrences and only observing the protocol source code and the set of messages already published, can join the network at any moment and determine the score of every potential chain, thereby identifying the block atop the highest-scoring main chain. Regarding proof of stake, as previously mentioned, such a property cannot be realized, given that it is quite inexpensive to acquire historical keys and simulate alternative histories. Therefore, we will slightly relax our assumptions: we will assert that we are solely focused on maintaining consensus among a fixed set of nodes that are online at least once every N days, permitting these nodes to utilize their historical knowledge to dismiss evident long-range forks via some formula, and new nodes or long-dormant nodes will be required to specify a “checkpoint” (a hash of a block denoting what the rest of the network acknowledges as a recent state) to re-enter consensus.

Such a method is, in essence, a blend of the pure and possibly severe trust-no-one logic of Bitcoin and the complete reliance on socially-driven consensus encountered in networks like Ripple. In Ripple’s scenario, users entering the system must choose a set of nodes they trust (or, more specifically, trust not to collude) and depend on those nodes throughout every stage of the consensus process. In Bitcoin’s framework, the theory posits that no such trust is necessary and the protocol is entirely self-sufficient; the system functions equally well among a thousand isolated cavemen with laptops on thousand islands as it does within a strongly interconnected society (in fact, it might operate more effectively with island cavemen since collusion is more challenging without trust). In our blended scheme, users merely need to look outside the protocol once – when they initially download a client and locate a checkpoint – and can enjoy Bitcoin-like trust characteristics starting from that juncture.

To ascertain which trust premise is the more advantageous one to adopt, we ultimately must pose a somewhat philosophical inquiry: do we desire our consensus protocols to function as absolute cryptoeconomic constructs that are entirely independent of the external world, or are we comfortable relying significantly on the context that these systems operate within a broader society? While it is indeed a core principle of mainstream cryptocurrency ideology that excessive external dependence is perilous, it could be argued that the extent of independence that Bitcoin offers us in practice is no greater than that provided by the hybrid model. The argument is straightforward: even in the case of Bitcoin, a user must also make a leap of trust upon entering the network – firstly by relying on the notion that they are joining a protocol that contains assets that others deem valuable (e.g., how does a user ascertain that bitcoins are worth $380 each and dogecoins merely $0.0004? Especially considering the varying capabilities of ASICs for differing algorithms, hash power is only a very rough estimate), and secondly by trusting that they are downloading the correct software package. In both the supposedly “pure” model and the hybrid model, there is always a need to reference the external world precisely once. Hence, overall, the advantage of embracing the additional trust requirement (namely, environmental friendliness and security against oligopolistic mining coalitions and ASIC farms) is arguably justifiable in terms of value.

Moreover, it is noteworthy that, unlike Ripple’s consensus, the hybrid framework remains compatible with the concept of blockchains “communicating” with one another by incorporating a minimal “light” implementation of each other’s protocols. The rationale here is that, while the scoring system is not “definitive” from the perspective of a node without a history suddenly referencing every block, it is entirely adequate for an entity that stays connected over an extended period, and a blockchain certainly qualifies as such an entity.

Up to this point, there have been two primary methodologies that adhered to a checkpoint-based trust paradigm:

1. Developer-issued checkpoints – the client developer releases a new checkpoint with each client iteration (e.g., utilized in PPCoin)
2. Reversion limit – nodes decline to recognize forks that revert more than N (e.g., 3000) blocks (e.g., utilized in Tendermint)

The initial strategy has faced significant criticism from the cryptocurrency community for being excessively centralized. The latter approach, however, also presents a drawback: a potent adversary can not only revert a handful of blocks but also potentially create a permanent network split. In the case of the N-block reversion, the strategy unfolds as follows. Imagine that the network is currently at block 10000, and N = 3000. The attacker initiates a covert fork and expands it by 3001 blocks with greater speed than the primary network. Once the main network reaches 12999, and a node generates block 13000, the attacker unveils his own fork. Some nodes will acknowledge the main network’s block 13000 and resist switching to the attacker’s fork, but those nodes that have not yet witnessed that block will be eager to revert from 12999 to 10000 and subsequently accept the attacker’s fork. From that moment, the network becomes irreversibly divided.

Fortunately, one can indeed conceptualize a third methodology that effectively addresses this issue, which we shall refer to as exponentially subjective scoring. Essentially, instead of dismissing forks that trace back too far, we simply apply penalties on a progressive scale. For each block, a node upholds a score and a “gravity” factor, which functions as a multiplier to the contribution that the block bestows upon the blockchain’s score. The gravity of the genesis block is set to 1, and generally, the gravity of any other block is calibrated to match the gravity of its parent. However, if a node encounters a block whose parent already possesses a lineage of N successors (i.e., it’s a fork reverting N blocks), that block’s gravity incurs a penalty of 0.99^N, and the penalty continues to propagate indefinitely down the lineage and amplifies multiplicatively with other penalties.

In other words, a fork that originates 1 block prior will need to accelerate by 1% more than the main chain to surpass it, a fork that begins 100 blocks ago must escalate at a rate 2.718 times faster, and a fork that starts 3000 blocks in the past will need to increase 12428428189813 times as rapidly – clearly unfeasible even with minimal proof of work.

The algorithm enables a more leveled approach to checkpointing, assigning a minor “weak checkpoint” role to each respective block. If an aggressor creates a fork that certain nodes detect even three blocks before others, those two chains will need to maintain a proximity of 3% to one another indefinitely for a network split to persist.

There are alternative solutions that could be employed in addition to, or even in conjunction with, ESS; a particular collection of tactics entails stakeholders voting on a checkpoint every few thousand blocks, necessitating every generated checkpoint to reflect a substantial accord of the majority of the current stake (the rationale behind the majority of the stake not voting on every block is, of course, that amassing that many signatures would bloat the blockchain).

Slasher Ghost

The other significant complication in executing proof of stake for Ethereum specifically is the fact that the network encompasses a Turing-complete financial ecosystem where accounts can hold arbitrary permissions and even permissions that fluctuate over time. In a basic currency system, proof of stake is relatively straightforward because each unit of currency has a clear owner outside the ecosystem, and that owner can be relied upon to engage in the stake-voting process by signing a message with the private key that represents the ownership of the coins. In Ethereum, however, matters are not as simple: if we perform our role of promoting appropriate wallet security correctly, the majority of ether will likely be stored in specialized storage contracts, and with Turing-complete code, there is no definitively clear means of identifying or assigning an “owner”.

One strategy we evaluated involved delegation: mandating that every address or contract designate an address as a delegate to sign on their behalf, and that delegate account would need to be governed by a private key. Nevertheless, there is an inherent issue with any such strategy. Suppose the majority of ether in the ecosystem is actually preserved in application contracts (as opposed to personal storage contracts); this encompasses deposits in SchellingCoins and various stake-based protocols, security deposits in probabilistic enforcement systems, collateral for financial derivatives, assets owned by DAOs, etc. Those contracts lack an owner even in principle; in such scenarios, the apprehension is that the contract will default to a strategy of auctioning stake-voting delegations to the highest bidder. As attackers are the only entities motivated to bid more than the anticipated returns from the delegations, this will render it exceedingly affordable for an attacker to procure signing rights to substantial quantities of stake.

The sole resolution to this within the delegation framework is to make it extremely perilous to assign signing rights to untrustworthy parties; the most straightforward approach is to modify Slasher to require a hefty deposit, and penalize the deposit along with the reward in the event of double-signing. However, if we adopt this, we essentially return to relying the fate of a significant amount of funds on a solitary private key, thus undermining much of the rationale behind Ethereum from the outset.

Fortunately, there exists one alternative to delegation that is somewhat more effective: allowing contracts themselves to sign. To comprehend how this functions, consider the following protocol:

1. A SIGN opcode has now been introduced.
2. A signature constitutes a series of virtual transactions which, when consecutively applied to the state at the conclusion of the parent block, leads to the activation of the SIGN opcode. The nonce of the initial VTX within the signature must be the prevhash being signed, the nonce of the subsequent one must be the prevhash incremented by one, and so on (alternatively, we can assign the nonces -1, -2, -3, etc., and necessitate the prevhash to be included through transaction data to be ultimately provided as input to the SIGN opcode).
3. When the block is executed, the state transitions from the VTXs are undone (this is the meaning of “virtual”), but a deposit is deducted from each signing contract, and the contract is recorded to receive the deposit and reward in 3000 blocks.

Essentially, it is the responsibility of the contract to establish the access policy for signing, and the contract achieves this by placing the SIGN opcode behind the suitable set of conditional statements. A signature now transforms into a collection of transactions that collectively meet this access policy. The motivation for contract developers to maintain this policy securely, and not hand it out to anyone who inquires, is that if it is not safeguarded, then an individual can double-sign with it and nullify the signing deposit, appropriating a portion for themselves as dictated by the Slasher protocol. Some contracts will continue to delegate, but this is unavoidable; even in proof-of-stake frameworks for standard currencies like NXT, numerous users end up delegating (for example, DPOS even institutionalizes delegation), and at least in this context, contracts possess an incentive to delegate to an access policy that is unlikely to fall under the sway of a malevolent entity – indeed, we may even observe an equilibrium where contracts vie to provide secure blockchain-based stake pools that are the least likely to double-vote, thus enhancing security over time.

Nonetheless, the virtual-transactions-as-signatures concept introduces one issue: it is no longer simple to furnish an evidence transaction demonstrating two signatures by the same signer at the identical block height. Since the outcome of a transaction execution relies on the initial state, to verify whether a specific evidence transaction is valid, one must validate everything leading to the block in which the second signature was issued. Therefore, one essentially has to “integrate” the fork of a blockchain within the main chain. To accomplish this efficiently, a relatively straightforward proposal is a kind of “Slasher GHOST” protocol, whereby one can incorporate side-blocks into the main chain as uncles. Specifically, we propose two new transaction types:

1. [block_number, uncle_hash] – this transaction is deemed valid if (1) the block associated with the specified uncle_hash has already been authenticated, (2) the block with the indicated uncle_hash has the corresponding block number, and (3) the parent of that uncle is either part of the main chain or was previously included as an uncle. During the processing of this transaction, if addresses that double-signed at that height are discovered, they are duly penalized.
2. [block_number, uncle_parent_hash, vtx] – this transaction is legitimate if (1) the block associated with the specified uncle_parent_hash has already been validated, (2) the provided virtual transaction is valid at the specified block height with the state at the end of uncle_parent_hash, and (3) the virtual transaction displays a signature from an address that also signed a block at the indicated block_number in the main chain. This transaction imposes a penalty on that particular address.

In essence, one may conceive of the mechanism functioning like a “zipper”, with one block from the fork chain being integrated into the main chain at a time. It is important to note that for a fork to initiate, there must be double-signers at each block; there is no circumstance where there exists a double-signer 1500 blocks into a fork, thus a whistleblower must “zip” 1499 unblemished blocks into a chain before reaching the target block – in situations like this, even if 1500 blocks need to be incorporated, each one of them alerts the main chain about several separate wrongdoers that double-signed at that height. One somewhat intricate property of the scheme is that the legitimacy of these “Slasher uncles” hinges on whether or not the node has validated a specific block outside of the main chain; to facilitate this, we stipulate that a response to a “getblock” message in the wire protocol must encompass the uncle-dependencies for a block prior to the actual block. It should be noted that this may occasionally lead to recursive expansion; however, the potential for denial-of-service is restricted since each individual block still necessitates a considerable amount of proof-of-work to create.

Blockmakers and Overrides

Ultimately, a third complication arises. In the hybrid-proof-of-stake variant of Slasher, if a miner possesses a dominant share of the hashpower, that miner can generate multiple versions of each block and send varying versions to different segments of the network. Half the signers will witness and sign one block, while the other half will see and sign another block, ultimately leaving the network with two blocks that lack sufficient signatures and no signer willing to slash themselves to finalize the process; consequently, a proof-of-work override will be necessary, creating a precarious situation as the miner controls most of the proof-of-work. There are two potential solutions here:

1. Signers should delay a few seconds after receiving a block before signing, and only sign stochastically in some manner that guarantees a random block will prevail.
2. A singular “blockmaker” among the signers should be established, whose signature is indispensable for a block to be deemed valid. Effectively, this shifts the “leadership” role from a miner to a stakeholder, resolving the issue, but it introduces a dependency on a single entity that now possesses the power to significantly inconvenience everyone by abstaining from signing, or inadvertently by becoming the target of a denial-of-service attack. Such actions can be disincentivized through a system where the signer forfeits part of their deposit if they fail to sign, yet this still results in a rather erratic block time if the only alternative to handle an absent blockmaker is resorting to a proof-of-work override.

A possible resolution to the issue in (2) is to eliminate proof of work entirely (or nearly so, retaining a minimal amount for anti-DDoS purposes), replacing it with a mechanism that Vlad Zamfir has termed “delegated timestamping.” Essentially, every block must emerge on schedule (for instance, every 15 seconds), and when a block is produced, the signers cast a vote of 1 if the block was punctual, or 0 if the block was either too early or too late. If the majority of the signers vote 0, then the block is considered invalid – kept in the chain to ensure that the signers receive their fair reward, but the blockmaker does not earn any reward and the state transition is bypassed. Voting is incentivized via schellingcoin – the participants whose votes coincide with the majority receive an additional benefit, thus presuming that everyone else is going to remain truthful, everyone is incentivized to act honestly, creating a self-reinforcing equilibrium. The hypothesis is that a block generation time of 15 seconds is too rapid for participants to agree on a false vote (the observant reader might point out that the participants were selected 3000 blocks prior, so this notion isn’t entirely accurate; to amend this, we can establish two factions of participants, one pre-selected group for validation and another selected at the time of block creation for timestamp voting).

Integrating Everything Together

When combined, we can discern a workable iteration of Slasher as follows:

1. Each block has a designated block producer, a grouping of appointed participants, and a collection of appointed timestamp providers. For a block to be validated as part of the blockchain, it must be accompanied by virtual transactions as signatures from the block producer, two-thirds of the participants, and 10 timestamp providers, with the block needing a minimal proof of work to protect against DDoS attacks (for example, targeted to 0.01x per year)
2. During block N, we assert that the collection of potential participants for block N + 3000 consists of addresses where sha3(address + block[N].hash) such that D2 is a difficulty parameter aiming for 15 participants each block (i.e., if block N has fewer than 15 participants, it decreases; otherwise, it increases).
3. If a prospective participant for block N + 3000 wishes to become a participant, they need to submit a distinct transaction accepting this obligation and providing a deposit, and that transaction must be included between blocks N + 1 and N + 64. The collection of appointed participants for block N + 3000 is the group of individuals that take this action, and the block producer is the appointed participant with the lowest value for sha3(address + block[N].hash). If there are no participants, no block can be produced at that height. For blocks 0 … 2999, the block producer and sole participant is the protocol developer.
4. The group of timestamp providers for block N + 3000 is the set of addresses such that sha3(address + block[N].hash) , where D3 is aiming for an average of 20 timestamp providers for each block (i.e., if block N has fewer than 20 timestamp providers, it decreases; otherwise, it increases).
5. Let T signify the timestamp of the genesis block. At the release of block N + 3000, timestamp providers can offer virtual transactions as signatures for that block, with the option to vote 0 or 1 on the block. Voting 1 indicates that they observed the block within 7.5 seconds of time T + (N + 3000) * 15, while voting 0 means they received the block when the time fell outside that range. Note that nodes should identify if their clocks are out of sync with others’ clocks on the blockchain, and if so, adjust their system clocks.
6. Timestamp providers who vote in alignment with the majority earn a reward; other timestamp providers receive nothing.
7. The appointed participants for block N + 3000 can endorse that block by supplying a set of virtual transactions as a signature. All appointed participants who sign are set to receive a reward alongside their returned deposit in block N + 6000. Participants who withdraw are scheduled to receive their returned deposit reduced by twice the reward (which implies that it is only economically beneficial to register as a participant if one believes there is a likelihood greater than 2/3 that they will be online).
8. If the majority vote from timestamp providers is 1, the block producer is scheduled to receive a reward and their returned deposit in block N + 6000. If the majority vote from timestamp providers is 0, the block producer is set to receive their deposit minus twice the reward, and the block is disregarded (i.e., the block remains in the chain, but it does not add to the chain’s score, and the state of the subsequent block resets from the final state of the block preceding the rejected block).
9. If a participant signs two distinct blocks at height N + 3000, then if someone detects the dual signing before block N + 6000, they can submit a “proof” transaction containing the two signatures to either or both chains, forfeiting the participant’s reward and deposit while transferring a third of it to the whistleblower.
10. If there is an inadequate number of participants to sign or the block producer is absent at a specific block height h, the designated block producer for height h + 1 may create a block directly atop the block at height h – 1 after a wait of 30 seconds instead of 15.

After extensive research, one thing is evident: proof of stake is complex – so complex that some even regard it as infeasible. The challenges of nothing-at-stake and long-range attacks, alongside the absence of mining as a limiting factor, necessitate several compensatory strategies, and the protocol outlined above does not resolve the issue of how to randomly choose participants. With a significant proof of work reward, the dilemma is mitigated, as block hashes can serve as a source of randomness, and we can mathematically demonstrate that the benefit from withholding block hashes until a miner discovers a hash that advantageously selects future participants is generally less than the gain from releasing the block hashes. Absent such a reward, however, alternative sources of randomness, like low-influence functions, need to be deployed.

For Ethereum 1.0, we find it very important to neither excessively delay the deployment nor attempt too many untested features simultaneously; therefore, we are likely to persist with ASIC-resistant proof of work, possibly incorporating non-Slasher proof of activity as a supplementary measure, while considering a transition to a more extensive proof of stake model over time.