Andromeda Upgrade [Full Agora Post — 7 min read] Andromeda is the first major upgrade in a two-step roadmap to drastically reduce transaction time to finality on MultiversX. This release redesigns consensus mechanisms, finalization rules, and cross-shard execution, significantly improving the efficiency, security, and scalability of the network. Why was Andromeda needed? The pre-Andromeda model introduced certain compromises to ensure security and Byzantine Fault Tolerance (BFT). These mechanisms were necessary trade-offs at the time but came with some drawbacks: 1) Confirmation blocks on execution shards and metachain were needed to protect against equivocation. 2) On execution shards the smaller consensus group (63 out of 400 eligible) was used to reduce computational overhead but required two rounds to ensure majority agreement. 3) The proposer-based finalization model ensured a clear consensus leader but created a single point of failure. 4) Cross-shard execution required extra notarization steps to ensure consistency, but this slowed transaction finality. 5) Validator selection changed every block, ensuring decentralization but made cross-chain proof verification cumbersome. What does Andromeda change? a) Removes confirmation blocks, cutting finality time in half. b) Eliminates equivocation risks by decentralizing each block consensus finalization. c) Optimizes cross-shard execution, reducing the required steps. d) Increases consensus participation in execution shards from 63 to 400, ensuring a single-shot consensus majority. e) Standardizes consensus validator sets across an epoch, simplifying verification. f) Fairer rewards distribution, as all validators now participate equally in consensus. This upgrade not only fixes these inefficiencies but also lays the foundation for Supernova, the next phase, which will reduce block time from 6s to 600ms, leading to 20× faster finality. // In depth analysis of Andromeda improvements ————————— ℹ️ I1. Increasing consensus size in execution shards to full eligible nodes set Prior to Andromeda, each execution shard used a randomly sampled consensus group of 63 nodes—selected from the 400 eligible validators—to validate and sign each proposed block. However, this approach did not guarantee that a block had majority acceptance from the entire shard within a single consensus round, particularly in a Byzantine environment. As a result, execution shards required a second confirmation block to strengthen acceptance rate. The MetaChain was an exception to this model, as it already used the full set of eligible nodes in the consensus group for each block. Why was 63/400 used for execution shards before Andromeda? • To reduce CPU overhead on execution shards, allowing more resources to be allocated to transaction execution rather than signature verification. • Reducing the number of nodes signing each block helped keep block times low. What changed to allow 400/400 consensus? • Rogue key protection via KOSK (Knowledge of Secret Key): This removed the need to embed rogue-key protection directly into aggregation, allowing secure large-group signature validation in shorter time. • Optimistic aggregation and verification of signatures: This reduced the CPU burden of verifying 400 individual signatures, making full-node consensus feasible. Why Is 400/400 better? • A single consensus round now proves majority acceptance, eliminating the need for two consecutive 63/400 consensuses. • Stronger security and faster finality, since every block represents full shard agreement, and under BFT assumptions eliminates all possibilities of reaching consensus on maliciously proposed blocks. • Simpler validator selection and fairer rewards distribution, as all validators now participate equally in consensus. ————————— ℹ️ I2. Eliminating confirmation blocks on Metachain and execution shards Why were confirmation blocks originally needed for Metachain? • In the pre-Andromeda model, a block could be proposed and pass consensus but still be at risk of being reverted even on Metachain which already had a 400/400 consensus group. • This is because consensus on the block did not guarantee absolute finality—a block could still be challenged if an alternative block appeared. • To ensure a block was truly final, a confirmation block was required before Metachain accepted it as final and valid. Why are confirmation blocks no longer needed? • Andromeda introduces Equivalent Consensus Proofs—these (together with the full size consensus on execution shard) guarantee instant finality for all blocks. • Since every block is final immediately upon consensus, the Metachain no longer needs confirmation blocks to validate a block’s finality. • Effect: Transaction finality time is cut in half. ————————— ℹ️ I3. How do equivalent consensus proofs solve equivocation Before Andromeda, equivocation between blocks that had already passed consensus was possible because the block proposer (consensus leader) retained partial control over the consensus finalization process of their proposed block. Why was leader-based finalization needed? • Before Andromeda, the leader (proposer) was responsible for: ○ Proposing a block; ○ Aggregating BLS signatures from 2/3 + 1 of the consensus group; ○ Finalizing the block by attaching proof before propagating it. • This ensured that only one version of the block was propagated if the leader was honest. What problems did this create? a) Equivocation risk: • A malicious leader could finalize two conflicting versions of a block by aggregating different subsets of valid signatures. Pre-Andromeda a fork choice rule would deterministically favor one block among the multiple possibilities. • Delay finalizing the block until a competing block appears in the next slot and then propagate his finalized block. b) Single point of failure: • If the leader went offline or delayed block propagation, the network assumed the block was lost c) Delayed consensus finalization: • Other nodes had to wait for the leader to finalize the block, introducing centralization risks. How does Andromeda solve this? • Equivalent Consensus Proofs allow any node in the consensus group to finalize the block. • The finalization proof is now separate from the block, meaning propagation delays cannot cause equivocation. • Effect: Equivocation is no longer possible, and consensus is more resilient to proposer failures. ————————— ℹ️ I4. How is cross shard execution changed with Andromeda Cross-shard execution—where a transaction involves accounts or applications across multiple shards—previously required at least six rounds to complete. Only after these six steps could the execution results be confirmed on the destination shard, allowing the MetaChain to notarize them and provide finality. Why did cross-shard execution require so many steps? Why was this necessary? • These steps ensure that every step of the cross-shard execution that happens in a different shard can not cause chain reverts in other shards. • However, they significantly slowed transaction finality. How does Andromeda optimize this? ————————— ℹ️ I5. Decreasing cross-chain proof verification complexity When proving that a block has reached consensus on one chain to another chain, multiple pieces of data must be transferred to enable proper verification. This includes information about the validator set responsible for reaching consensus on the block, as well as finality data that ensures the block is immutable and can no longer be reverted. Why did cross-chain proofs require extra metadata? • Pre-Andromeda, only 63 out of 400 nodes participated in each consensus group. • To verify a consensus proof externally, the cross-chain system had to: ○ Reconstruct how the 63 nodes were selected. ○ Verify the aggregated signature taking into account the aggregation order of their signatures. ○ This added significant metadata overhead to every proof. How does Andromeda simplify cross-chain proofs? • All 400 nodes participate in every consensus round in one epoch. • Signature aggregation follows a fixed order instead of shuffling. • Now, cross-chain verifiers only need the validator set once per epoch, instead of recalculating it for every block. • Effect: Cross-chain proofs are smaller, easier to verify, and require less data. ————————— // The solutions and their impact ————————— // Conclusion Andromeda represents a major milestone in improving transaction speed, security, and cross-shard execution in MultiversX. By eliminating confirmation blocks, removing equivocation risks, and streamlining network propagation, this upgrade lays the foundation for Supernova. Key benefits of Andromeda • Transaction finality is now instant—no need for confirmation blocks, if there exists a consensus proof, the block is final. • Cross-shard execution is 2× faster—cutting total steps from 6 blocks to 3 blocks. • No risk of equivocation—finalization is decentralized, eliminating leader control. • Faster network propagation—proofs spread in parallel, reducing delays. • Cross-chain verification is simpler—fixed validator sets remove unnecessary metadata. • Prepares the network for Supernova, enabling 600ms block times and parallel execution. With Andromeda and Supernova combined, MultiversX will achieve a 20× improvement in transaction finality, making it one of the fastest, most scalable and secure blockchain networks in existence.