SIMD-0204: Slashable event verification #204

AshwinSekar · 2024-11-26T18:00:33Z

Proposal to deploy a program that records and verifies slashable events on chain

This proposal does not modify any stakes or rewards, the program will only verify and record infractions.

At the moment we only verify duplicate block violations, but a future SIMD will add voting violations as well

joncinque

Really great work! Most of my comments are minor nits for clarification

joncinque · 2024-12-02T22:40:22Z

proposals/0204-slashable-event-verification.md

+
+`DuplicateBlockProof` requires 1 account:
+
+0. `proof_account`, expected to be previously intiialized with the proof data.


nit typo

Suggested change

0. `proof_account`, expected to be previously intiialized with the proof data.

0. `proof_account`, expected to be previously initialized with the proof data.

joncinque · 2024-12-02T22:44:41Z

proposals/0204-slashable-event-verification.md

+The first 4 bytes correspond to the length of the first shred, and the 4 bytes
+after that shred correspond to the length of the second shred.


Like the other fields, it's probably worth specifying that these are unaligned four-byte little-endian unsigned ints

joncinque · 2024-12-02T22:46:57Z

proposals/0204-slashable-event-verification.md

+On the epoch boundary where the `create_slashing_program` feature flag is first
+activated the following behavior will be executed in the first block for the new
+epoch:


It might be worth calling out that these steps are the only things that nodes need to implement at the moment, and to have the program details under a separate heading for clarity.

I almost wonder if we should separate this into two SIMDs: one for just the program upgrade portion, and another for the on-chain duplicate block check. I don't feel that strongly though, so let's keep it as is for now

As you said this is the only protocol change, the remaining bits are just how the program works.
It felt weird to have a SIMD with only the upgrading logic, a reader of the SIMD shouldn't give approval without at least reading the program spec.

If we wanted to keep it simpler we could have this SIMD just be the upgrade bit, and the remaining explanation of the program as part of the spl docs.

joncinque · 2024-12-02T22:47:42Z

proposals/0204-slashable-event-verification.md

+2. Verify that the program account
+  `8sT74BE7sanh4iT84EyVUL8b77cVruLHXGjvTyJ4GwCe` has a verified build hash of
+  `<FILL IN AFTER IMPLEMENTATION>` [\[1\]](#notes)


We don't typically do this when upgrading a program via feature gate, but I like it a lot! We should definitely start

joncinque · 2024-12-02T22:49:29Z

proposals/0204-slashable-event-verification.md

+3. Copy the contents of `8sT74BE7sanh4iT84EyVUL8b77cVruLHXGjvTyJ4GwCe` into
+  `S1ashing11111111111111111111111111111111111`


Do you intend for S1ashing11111111111111111111111111111111111 to be owned by the upgradeable loader or loader-v4? If it's the former, we should also move the program-data account from the old address to the PDA for S1ashing11111111111111111111111111111111111, to ensure that the program behaves like any other BPF program. cc @buffalojoec

Not familiar with the loaders so i'll defer to your wisdom :), just let me know which one makes the most sense and I can include it here.

Let's go with the default loader (bpf-loader-upgradeable) for now. We can amend it if loader-v4 becomes the default sooner than this.

joncinque · 2024-12-02T23:32:16Z

proposals/0204-slashable-event-verification.md

+  the `Clock` sysvar. We want to ensure that these accounts do not get closed before
+  they are observed by indexers and dashboards.
+
+Otherwise we close the `report_account` and credit the `lamports` to `destination`


nit: can be super clear and specify that closing entails setting the owner to the system program and reallocating the account to 0 bytes

joncinque · 2024-12-02T23:33:35Z

proposals/0204-slashable-event-verification.md

+- `violation_type` is not `0x00` (corresponds to `DuplicateBlock` violation)
+- Deriving the pda using `pubkey`, `slot`, and `ViolationType::DuplicateBlock`
+  as outlined above does not result in the adddress of `report_account`
+- `report_account` is not writeable


We probably don't need this check -- the runtime will do this for us when we try to write to it. On the flip side, we probably want to check that it's owned by the slashing program

joncinque · 2024-12-02T23:35:17Z

proposals/0204-slashable-event-verification.md

+They can accomplish this via the `CloseProofReport` instruction which requires
+2 accounts:


Sounds like it needs one more account -- the reporter to sign. But I wonder if we can allow this to be totally permissionless by having the reporter provide the lamport destination when they create the report. That way we're sure slash reports are always cleaned up.

I like that approach, can definitely see people forgetting to close their reports

Could we just send it back to the initial reporter? Or is it worth carrying around a separate address as the destination

I'd keep them separate -- it gives extra flexibility and clarity at the cost of an extra 32 bytes, which shouldn't be too bad, especially considering the accounts will get cleaned up

joncinque · 2024-12-02T23:35:43Z

proposals/0204-slashable-event-verification.md

+- `violation_type`, a one byte value acting as the violation type discriminator
+- `slot`, an unaligned eight-byte little-endian unsigned integer indicating the
+  slot which was reported
+- `pubkey`, an unaligned 32 byte array representing the public key of the node
+  which was reported


Are these parameters actually needed? I think we'll be OK without them

joncinque · 2024-12-02T23:39:48Z

proposals/0204-slashable-event-verification.md

+- `report_account.epoch + 3` is greater than the current epoch reported from
+  the `Clock` sysvar. We want to ensure that these accounts do not get closed before
+  they are observed by indexers and dashboards.


Is there any other rationale for this number, like association to the leader schedule or time for stake / vote accounts to get penalized? It's ok if there isn't, but it would be good to spell it out.

lidatong · 2024-12-08T20:56:42Z

proposals/0204-slashable-event-verification.md

+- Both shreds specify the same index and shred type, however their payloads
+  differ
+- Both shreds specify the same FEC set, however their merkle roots differ


will there be a feature gate to deprecate / drop all shreds except chained merkles? that would simplify this check to just the comparing signature (memcmp 64 bytes vs. 1228) which could add up

yes we will eventually drop all unchained merkle shreds once it's fully rolled out anza-xyz/agave#2149

Which check are you referring to? Or do you mean that we just compare the signatures instead of the merkle roots? That could work since we already validate the merkle root -> signature as part of the sigverify section.

lidatong · 2024-12-08T20:57:11Z

proposals/0204-slashable-event-verification.md

+- Both shreds specify the same FEC set, however their merkle roots differ
+- Both shreds specify the same FEC set and are coding shreds, however their
+  erasure configs conflict
+- At least one shred is a coding shred, and its erasure meta indicates an FEC set


in particular, the shred with the lower FEC set index has to be the coding shred right? and the other can be data or coding

Yeah that's correct I'll update the language

AshwinSekar force-pushed the slashing-program branch from 67179d1 to 061cf5f Compare November 26, 2024 18:02

AshwinSekar changed the title ~~SIMD-0XXX: Slashable event verification~~ SIMD-0204: Slashable event verification Nov 26, 2024

AshwinSekar force-pushed the slashing-program branch 4 times, most recently from 2d2ee08 to 339aa9a Compare November 26, 2024 18:27

SIMD-0204: Slashable event verification

4f69f15

AshwinSekar force-pushed the slashing-program branch from 339aa9a to 4f69f15 Compare November 26, 2024 19:07

AshwinSekar marked this pull request as ready for review November 26, 2024 19:12

AshwinSekar requested a review from joncinque November 26, 2024 19:13

AshwinSekar mentioned this pull request Nov 26, 2024

slashing: add duplicate block proof verification solana-labs/solana-program-library#7418

Merged

github-actions bot mentioned this pull request Dec 2, 2024

Upstream Updates - Mon Dec 2 00:15:55 UTC 2024 smartcontractkit/chainlink-solana#952

Closed

joncinque reviewed Dec 2, 2024

View reviewed changes

AshwinSekar added 4 commits December 3, 2024 13:57

pr feedback

c8b42fc

make close account permissionless

b980cb1

spell out three epoch window rational

bd9d399

duplicate proof -> duplicate block proof

0d13374

AshwinSekar force-pushed the slashing-program branch from 5cf8254 to 0d13374 Compare December 3, 2024 19:05

AshwinSekar requested a review from joncinque December 3, 2024 19:06

AshwinSekar added 2 commits December 3, 2024 15:17

remove lamport check in favor of data check

472c2b4

instructions sysvar

c47359f

lidatong reviewed Dec 8, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SIMD-0204: Slashable event verification #204

SIMD-0204: Slashable event verification #204

AshwinSekar commented Nov 26, 2024 •

edited

Loading

joncinque left a comment

joncinque Dec 2, 2024

joncinque Dec 2, 2024

joncinque Dec 2, 2024

AshwinSekar Dec 3, 2024

joncinque Dec 2, 2024

joncinque Dec 2, 2024

AshwinSekar Dec 3, 2024

joncinque Dec 4, 2024 •

edited

Loading

joncinque Dec 2, 2024

joncinque Dec 2, 2024

joncinque Dec 2, 2024

AshwinSekar Dec 3, 2024

AshwinSekar Dec 3, 2024

joncinque Dec 4, 2024

joncinque Dec 2, 2024

joncinque Dec 2, 2024

lidatong Dec 8, 2024

AshwinSekar Dec 11, 2024

lidatong Dec 8, 2024

AshwinSekar Dec 11, 2024


		`DuplicateBlockProof` requires 1 account:

		0. `proof_account`, expected to be previously intiialized with the proof data.

		The first 4 bytes correspond to the length of the first shred, and the 4 bytes
		after that shred correspond to the length of the second shred.

		3. Copy the contents of `8sT74BE7sanh4iT84EyVUL8b77cVruLHXGjvTyJ4GwCe` into
		`S1ashing11111111111111111111111111111111111`

		They can accomplish this via the `CloseProofReport` instruction which requires
		2 accounts:

SIMD-0204: Slashable event verification #204

Are you sure you want to change the base?

SIMD-0204: Slashable event verification #204

Conversation

AshwinSekar commented Nov 26, 2024 • edited Loading

joncinque left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joncinque Dec 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AshwinSekar commented Nov 26, 2024 •

edited

Loading

joncinque Dec 4, 2024 •

edited

Loading