TL;DR:
- IOTA moved Starfish consensus to mainnet through v1.21.1 and protocol version 24, targeting real-world network stress.
- Starfish shifts from Mysticeti’s pull recovery toward push-based data movement, reducing pull requests by about one order of magnitude before missing history reaches the critical path for lagging validators.
- The design separates metadata from payloads, uses Reed-Solomon fragments for availability, and accepts slightly higher ordinary latency to improve slower cases under pressure on mainnet.
IOTA has moved Starfish consensus onto mainnet through v1.21.1 and protocol version 24, introducing a push-based design meant to keep validators aligned when real networks get messy. The upgrade targets conditions where nodes slow down, messages arrive late or participants behave incorrectly. Synchronization becomes part of consensus, not a background chore, because a validator cannot vote on blocks it has not seen or certify transaction data it cannot rebuild. The result is a technical pivot with a practical question attached: can faster data movement reduce stress before missing blocks become bottlenecks for validators and users?
Starfish Pushes Data Before Validators Ask
Starfish builds on IOTA’s DAG, where blocks reference earlier blocks and reveal what validators have already observed. Under the earlier Mysticeti model, missing data was handled more through pull behavior: a validator detected a gap, asked peers for the missing block and waited. Pull-based recovery saved bandwidth in quiet conditions, but under pressure each missing item created another request, delay and recovery step. Starfish reverses that flow by pushing useful information forward before others request it, helping lagging nodes receive likely needed data before missing history reaches the critical path in production during heavy activity.
The architecture does not simply flood validators with complete transaction payloads. Starfish separates metadata from payloads, letting headers carry references, votes, acknowledgments, timing details and payload commitments while transaction data moves separately. Reed-Solomon encoding is the efficiency lever, splitting a block’s payload into fragments assigned across validators. The payload can be rebuilt from any sufficient subset of valid fragments: f+1 valid fragments can reconstruct it, while 2f+1 acknowledgments create the availability condition needed for Byzantine safety. That means validators do not all need the full payload at the same time across distributed validator sets.
The trade-off is explicit. Starfish uses more bandwidth than Mysticeti in tested conditions, but sends structured communication earlier to avoid expensive recovery later. IOTA’s outbound request graph showed pull requests falling by about one order of magnitude. Latency becomes a resilience trade-off, since adding an availability step before sequencing can slightly raise ordinary transaction latency, while improving slower cases and reducing time spent recovering missing information. The next proof point is operational: whether Starfish keeps IOTA aligned when real usage, imperfect validators and network pressure converge on mainnet without sacrificing availability under adverse conditions.
