In the current implementations of the Lightning network protocol (c-lightning, eclair and lnd), is there any check that stops spamming/flooding of channel_announcement, mode_announcement or channel_update messages? Assume that these messages are valid and provable.
The protocol is purposefully built in such a way that DoS attacks are mitigated and reduced in impact. Each
channel_announcement contains a reference to the funding transaction, and each node verifies that this funding transaction matches the information in the announcement. This makes the creation of a
channel_announcement non-free, and binds some resources of a potential attacker, and a channel may only be announced once.
channel_updates are only valid if they are preceded by a matching
channel_announcement making them also non-free. The same is true for
node_announcements which must be preceded by at least one
channel_announcement announcing a channel for that node.
channel_announcements are unique, this is not true for
node_announcements, which can update the parameters of a channel/node. To mitigate a potential flood of updates the protocol specifies that a staggered broadcast must be used, which buffers incoming gossip messages and waits 60 seconds for in-memory replacements before forwarding them. This coalesces multiple updates for the same channel or node into a single message then being actually broadcast. So if you attempt to broadcast loads of updates they'll be aggregated at the first hop, and only the latest one will ever be forwarded.
This reduces the number of messages that a node may broadcast to 1
channel_announcement per channel, and 1
node_announcement per node per 60 seconds and 1
channel_update per channel per 60 seconds.
(Disclaimer: I am one of the spec authors and the author of the staggered broadcast proposal)