Skip to content

gossipsub: define scoring and resource management semantics for partial messages#7

Open
RustamSheoran wants to merge 1 commit into
seetadev:masterfrom
RustamSheoran:gossipsub/v1.4/normative-scoring-resource-limits
Open

gossipsub: define scoring and resource management semantics for partial messages#7
RustamSheoran wants to merge 1 commit into
seetadev:masterfrom
RustamSheoran:gossipsub/v1.4/normative-scoring-resource-limits

Conversation

@RustamSheoran
Copy link
Copy Markdown

Overview

This PR adds normative scoring and resource-management semantics to the Gossipsub Partial Messages extension.

The current draft primarily defines segmentation and propagation wire formats, but leaves the interaction with the existing Gossipsub v1.1 scoring framework largely unspecified. This creates ambiguity around:

  • peer accountability
  • partial delivery semantics
  • resource exhaustion handling
  • segmented propagation under adversarial conditions

This PR formalizes how segmented propagation interacts with the existing scoring model while preserving implementation flexibility and backwards compatibility.


Key Changes

P₂: First Message Deliveries

  • Introduces the concept of eligible contributors for successfully reassembled messages.
  • Requires implementations to define attribution strategies that discourage "last segment wins" behavior.
  • Clarifies that segments received after successful reassembly MUST NOT receive P₂ credit.

P₃: Mesh Message Delivery Rate

  • Specifies that peers contributing valid segments to successfully reassembled messages SHOULD receive P₃ credit.
  • Ensures segmented propagation does not unintentionally penalize healthy mesh participants.

P₄: Invalid Messages

  • Mandates immediate P₄ penalties for individually verifiable invalid segments.
  • Allows delayed attribution when invalidity can only be determined after full reassembly.

P₇: Behavioural Penalties

Defines normative behavioural penalties for:

  • segment-flood attacks
  • dangling reassembly abuse
  • repeated "Broken Promise" behavior
  • invalid Group IDs

A "Broken Promise" refers to repeatedly advertising segment availability via partsMetadata while failing to deliver the requested parts beyond what can reasonably be attributed to network churn or transient packet loss.


Resource Management and DoS Mitigations

This PR also introduces normative bounded-resource requirements for segmented propagation, including:

  • bounded reassembly buffers
  • per-peer concurrent session limits
  • mandatory reassembly timeouts
  • eager-data acceptance limits
  • orphaned-session cleanup guidance

Additionally, cleanup of expired/orphaned sessions SHOULD be performed in O(1) or amortized constant-time complexity to reduce CPU exhaustion risk during adversarial floods.


Rationale

Segmented propagation introduces several new attack surfaces and scoring ambiguities that do not exist in atomic message delivery systems.

Without these semantics:

  • malicious peers can trigger unbounded reassembly growth
  • scoring systems may disproportionately reward terminal segment providers
  • honest peers contributing partial data may be penalized
  • implementations may diverge in handling incomplete or adversarial reassembly behavior

This PR aims to provide interoperable, production-oriented guidance while avoiding unnecessary protocol complexity.


Compatibility

  • Fully compatible with existing Gossipsub v1.1 scoring semantics.
  • Does not introduce new protobuf fields or protocol IDs.
  • Preserves implementation flexibility for scoring attribution strategies.
  • Integrates cleanly with existing v1.3 extension semantics.

Security Considerations

This PR directly addresses:

  • segment-flood attacks
  • dangling reassembly DoS vectors
  • state-exhaustion attacks
  • eager-data abuse
  • scoring distortion during segmented propagation

while maintaining compatibility with future large-data dissemination systems and DAS-style propagation models.

This update introduces normative requirements for integrating the
Partial Messages extension with the Gossipsub v1.1 Peer Scoring system.

- Define P2 credit attribution for "eligible contributors" to reassembled messages.
- Discourage "last segment wins" incentive distortion in scoring.
- Mandate P4 penalties for invalid message segments.
- Introduce P7 behavioural penalties for segment-flood and broken promises.
- Formalize mandatory resource bounds and O(1) cleanup requirements
  for reassembly buffers.

These changes ensure production-grade security and prevent state-exhaustion
attacks in segmented propagation.
@RustamSheoran
Copy link
Copy Markdown
Author

One design goal of this PR was to preserve compatibility with existing v1.1 scoring semantics while avoiding implementation-forcing proportional accounting rules.

The intent is to standardize minimum behavioural guarantees and resource bounds without over-constraining implementation-specific scoring strategies.

@RustamSheoran
Copy link
Copy Markdown
Author

Hi @seetadev @johannamoran,

I explored the interaction between the Partial Messages extension and the existing Gossipsub v1.1 scoring/resource-management model, and opened a PR focused on normative scoring semantics and bounded-resource guarantees for segmented propagation:

#7

The PR introduces:

  • P₂ contributor eligibility semantics
  • P₃ accounting guidance for segment contributors
  • P₄ handling for individually verifiable invalid segments
  • P₇ behavioural penalties for segment-flood and dangling reassembly abuse
  • bounded-memory and timeout requirements for reassembly state

One of the main goals was to preserve compatibility with existing v1.1 scoring assumptions while avoiding implementation-forcing proportional accounting rules.

Would appreciate feedback, especially around:

  • contributor attribution semantics
  • behavioural penalty boundaries
  • bounded-resource expectations under churn/adversarial conditions
  • interoperability implications for future DAS-style propagation systems

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant