Purpose

The merging of Activation Transactions (ATXs) serves multiple critical functions aimed at enhancing network efficiency and security. We landed on ATX merge as a solution to address the network growth and the unexpectedly high number of smeshing identities, which has been taxing the network due to individual optimizations by large smeshers. The ATX merge is designed to reduce network congestion and enhance overall performance and scalability.

ATX merging aims to respond to the growing load of the network by providing the following:

• Resource Efficiency: Merging ATXs allows multiple identities to be represented within a single transaction, reducing data processing and storage requirements, which can lower costs and accelerate processing times.
  
• Efficiency in Data Handling: The merging method optimizes data use by combining multiple post-proofs into a single ATX, saving data and streamlining transactions.
  

Description

The new ATX merge introduces a system where identities can “marry” (join an equivocation set) and “publish ATX together” (merge). Here’s a summary of the key points:

Marriage

Marriage combines identities into a single equivocation set. It occurs when one identity publishes an Activation Transaction (ATX) containing a marriage certificate, which are proofs of consent from other identities that wish to be bound together. The process is instantaneous once the (the marriage) ATX is published, but the intent to marry must be announced (by publishing a marriage ATX) two epochs in advance before a (merged) ATX combining married identities can be published. Marriage is irrevocable, binding the identities into a permanent equivocation set.

Marriage certificate in Epoch N-2:

• Alice signs Bob’s ID proving her willingness (intent) to marry Bob and creates a Marriage Certificate

• Bob creates an ATX including the Marriage Certificate created by Alice

   

Epoch N:

One of two scenarios can happen here:

1. Bob publishes a merged ATX including Alice’s PoST proof.
2. Alice and Bob create separate ATXs (Alice does not contribute her PoST proof to the combined ATX).

The “marriage” is instant and, from the moment Bob published the marriage ATX in epoch N-2, Alice and Bob are forever bound by forming a so-called equivocation set. Once they are linked together like this, they can never be un-linked, whether they publish a merged ATX or two separate ATXs. The option to publish separate ATXs after a “marriage” is given to Married IDs in case some of them malfunction. The system allows identities within the same set to publish separate ATXs if needed, such as in emergencies or if not all identities want to finalize a merge. The ATX that initiated the marriage serves as a reference point for syntactical verification of the identities’ bound status in future transactions.

The marriage certificate is optional (see code). This way, when Alice publishes alone, she does not need to add the reference. The reference is needed only when one of the IDs in the same equivocation set publishes a merged ATX—otherwise it is not a valid ATX.

Equivocation sets

An equivocation set refers to the group of “identities” joined by “marriage”. Any ID with a low-enough VRF nonce can publish a merged ATX. If any identity within the set acts maliciously, all are deemed malicious. The set is limited to a maximum of 256 identities (see code). Other IDs in the same set can publish ATXs separately but only ones with low enough VRF can publish a merged ATX on behalf of the whole set.

Merging

The merge Involves publishing a single ATX for multiple identities within an equivocation set. This ATX includes combined non-interactive proofs of space-time (NIPoST) for all involved identities, and is signed by the identity publishing it. The merged ATX uses a VRF nonce that corresponds to the combined storage of all included identities and becomes active for the target epoch. From there, it participates in network protocols and accumulates rewards based on the total weight of all identities in the ATX.

Malfeasance Proofs:

Proofs become malfeasant under the following two conditions:

1. For publishing more than one merged ATX per epoch. For example, if two IDs from the same set publish a merged ATX with the same certificate ref in the same epoch. Checking for this kind of malfeasance is done efficiently by looking for the certification references.
2. For doing more than 1 marriage certificate per identity. For example, A merged ATX from a married set A contains the marriage certificate for that set, another merged ATX for set B with marriage certificate for that set. If at least one identity is contained in both marriage certificates for set A and B then the proof becomes malfeasant. In other words, IDs can be part of a single set and sets cannot grow (at present). Checking for this kind of malfeasance is done efficiently with a Merkle proof. If proven, all identities (from both sets) become malfeasant.
   

Syntactical Invalidity:

Proofs become syntactically invalid if at least one of the following two conditions is true:

1. If the identities never announced their marriage or ATX contains a post of an identity that is not part of the equivocation set. This is a syntactical error because Alice must include a certificate or reference if she includes more than one PoST proof per ATX. If there is no certificate then it’s an invalid ATX
2. If one of the ATXs in a “marriage” includes an ID that wasn’t announced 2 epochs prior. This is proven syntactically invalid by the handler can fetch the marriage ATX and check the epoch in which it was published, which will determine whether both ATXs are married or not.

For the code of the Identity Merge, please see here.