This is a sketch of a proposal for a way to prove certain p2p interactions on chain. (I wanted to write it down somewhere, its by no means a complete proposal. If github issues aren't the correct place for this, lmk) This could be utilized to slash p2p nodes for malicious activity for instance. This doesn't help for full nodes syncing, but it does help all full nodes after syncing. With proofs of exclusion, we can even make this work for lite clients if there is a tag for p2p registration. At the moment I don't see any reason for why this would be desirable in a public blockchain network as it just disincentivizes full nodes with collateral lockup, but it may have utility in a private / permissioned network.

There are 3 independent challenges here.

• The first is having some on chain registry of p2p node ids to accounts, so that these node id's can be held accountable. This is a fairly straight-forward add-on, just make p2p node-ids known on chain at a particular location in state. However the above breaks abstraction barriers a bit, so we have to plan it out.
• The second is proving that a party sent you a given message, such that you can't forge the message and that it also doesn't reveal any other message in the exchange to an adversary that has monitored all p2p traffic. This is the problem that is solved by message franking, see this paper and its corresponding talk. We would be sacrificing some or all ephemerality, since you would have to keep the key exchange information until you feel like you won't need to report anything in that exchange. (Perhaps if an entire connection had no bad messages) To prove a message then, you'd provide a transcript for the keys generated having been authenticated by the corresponding node id, and then you perform the message franking on that.
• Figuring out what p2p conditions should be slashable / have reputation, and making the entire system handle p2p node evidence differently from validator evidence.

We'd have to evaluate the efficiency of the message franking scheme in practice. I haven't had a chance to read the full construction, so I'm unsure of the overhead.

cc @milosevic