SIMD-0204

TL;DR

This proposal describes an enshrined on-chain program to verify proofs that a validator committed a slashable infraction. This program creates reports on chain for use in future SIMDs. **This proposal does not modify any stakes or rewards, the program will only verify and log infractions.**

Summary

This proposal describes an enshrined on-chain program to verify proofs that a validator committed a slashable infraction. This program creates reports on chain for use in future SIMDs. **This proposal does not modify any stakes or rewards, the program will only verify and log infractions.**

Motivation

There exists a class of protocol violations that are difficult to detect synchronously, but are simple to detect after the fact. In order to penalize violators we provide a means to record these violations on chain. This also serves as a starting point for observability and discussions around the economics of penalizing these violators. This is a necessary step to implement slashing in the Solana Protocol.

Key Changes

• sProgVaNWkYdP2eTRAy1CPrgb3b9p8yXCASrPEqo6VJ
• Create a new program account at S1ashing11111111111111111111111111111111111 owned by the default upgradeable loader with an upgrade authority set to None, and create the associated program data account.
• Verify that the buffer account S1asHs4je6wPb2kWiHqNNdpNRiDaBEDQyfyCThhsrgv has a verified build hash of 192ed727334abe822d5accba8b886e25f88b03c76973c2e7290cfb55b9e1115f [\[1\]](#notes)
• Serialize the contents of S1asHs4je6wPb2kWiHqNNdpNRiDaBEDQyfyCThhsrgv into the program data account for S1ashing11111111111111111111111111111111111
• Invoke the loader to deploy the new program account and program data account. This step also updates the program cache.
• Zero out the buffer account S1asHs4je6wPb2kWiHqNNdpNRiDaBEDQyfyCThhsrgv, and update the changes to capitalization and account data lengths accordingly.
• proof_account, expected to be previously initialized with the proof data.
• report_account, the PDA in which to store the violation report. See the below section for details. Must be writable.
• instructions, Instructions sysvar
• system_program_account, required to create the violation report.
• 0x01, a fixed-value byte acting as the instruction discriminator
• offset, an unaligned eight-byte little-endian unsigned integer indicating the offset from which to read the proof
• slot, an unaligned eight-byte little-endian unsigned integer indicating the slot in which the violation occured
• node_pubkey, an unaligned 32 byte array representing the public key of the node which committed the violation
• reporter, an unaligned 32 byte array representing the account to credit as the first reporter of this violation if a successful slashing report is written.
• destination, an unaligned 32 byte array representing the account to reclaim the lamports if a successful slashing report account is created and then later closed.
• shred_1_merkle_root, an unaligned 32 byte array representing the merkle root of the first shred in the proof_account
• shred_1_signature, an unaligned 64 byte array representing the signature of node_pubkey on the first shred in the proof_account
• shred_2_merkle_root, an unaligned 32 byte array representing the merkle root of the second shred in the proof_account
• shred_2_signature, an unaligned 64 byte array representing the signature of node_pubkey on the second shred in the proof_account

Impact

A new program will be enshrined at `S1ashing11111111111111111111111111111111111`. Reports stored in PDAs of this program might be queried for dashboards which could incur additional indexing overhead for RPC providers.

Backwards Compatibility

The feature is not backwards compatible

Security Considerations

None