MLAR: Boxer Role in Decentralized Boxchain

• MLAR outlines the boxer role as the final node to close a box by meeting a dual-criteria of capacity or time, ensuring swift transaction confirmation.
• It employs a dual-validation process where each node, including the boxer, recursively checks its predecessor to maintain integrity and security.
• Randomized parameters such as box size and time limit are integrated to deter predictability, boosting decentralization and resistance to attacks.

Below is a consolidated, in-depth description of the “boxer” role in the boxchain protocol, drawing directly on the Definitions, Algorithms and Remarks of Lee & Choi’s paper. We cover:

1. A formal definition
2. Boxer‐designation steps (with pseudocode)
3. Boxer ↔ box-genesis ↔ augmenting-node interactions
4. Core formulas and security bounds
5. How the boxer enhances decentralization, security and efficiency

––––––––––––––––––––––––––––––––––––––––––––

1. Formal Definition, Role and Responsibilities of a Boxer Node

Definition (Boxer Node). Let Bₖ be the k-th antichain (“box”) in the dual ledger; its elements {vₖ^1,…,vₖ^m} are incomparable DAG-nodes that have each just approved two transactions in the previous box Bₖ₋₁. The boxer of box Bₖ, denoted bₖ, is the last such node admitted to Bₖ under the dual‐criteria (cardinality or time). As a “light” node, bₖ:

 * “Closes” Bₖ as soon as it arrives (triggers final‐confirmation for Bₖ₋₁).  * Broadcasts the closing event and a hash pointer of Bₖ₋₁’s confirmed transactions.  * Maintains a chain of boxer‐to‐boxer links (the semi-hidden “boxer network”).  * Serves as a check on the box-genesis by holding a copy of the final‐confirmed hash and timestamp.

Remark. A boxer never does the final, global confirmation itself; it delegates that to the box-genesis (a full node) chosen immediately after the boxer is fixed.

––––––––––––––––––––––––––––––––––––––––––––

2. Algorithmic Steps for Boxer Designation

The boxer is the last node v to join Bₖ when either (i) |Bₖ| reaches a predetermined upper bound M, or (ii) the elapsed time since the first member of Bₖ arrived exceeds τ.

Here M need not be fixed— it can be drawn randomly for each box via the “inversion method”— and τ is the per-box time limit.

Pseudocode sketch (combines Algorithms 1&2 plus the dual-criteria of Remark 2.3.3):

Input: M ← optional random draw via M = F_X^{-1}(U), τ > 0 Initialize Bₖ ← ∅, t₀ ← “now” Upon each new DAG node v that validates two tips in Bₖ₋₁: if v covers at least one element of Bₖ₋₁ then Bₖ ← Bₖ ∪ {v} if |Bₖ| = M or (current_time − t₀) > τ: designate bₖ ← v # this v is the boxer invoke box‐genesis selection trigger final‐confirmation of Bₖ₋₁ break # stop admitting new members to Bₖ else carry v forward to Bₖ₊₁’ # ready for next box

Randomization of M. Let X be a positive‐integer random variable with CDF F_X. Draw U ∼ Uniform(0,1), then set M = F_X⁻¹(U). This conditional randomization helps prevent an attacker from predicting in advance exactly how many approvals are needed to form a box.

Fallback (“time-first”) exception. If transaction arrival is excessively fast and |Bₖ| exceeds some internal safe threshold before τ, then τ governs the boxing.

––––––––––––––––––––––––––––––––––––––––––––

3. Boxer ↔ Box-Genesis ↔ Augmenting-Node Interactions

3.1 Dual 2 + 2 Validation (Recursive in-box checks) Every new member vᵢ of Bₖ upon arrival must:

a) have already validated (“approved”) two transactions from the previous boxes; b) immediately re-check its immediate predecessor vᵢ₋₁ ∈ Bₖ to ensure that vᵢ₋₁ indeed properly validated its two tips.

This “neighbor‐to‐neighbor” check propagates from the second member all the way up to the boxer bₖ.

3.2 Final Confirmation by the Box-Genesis (Algorithm 3) Once bₖ is fixed, a box-genesis gₖ is chosen at random among the good-standing nodes in Bₖ \ {bₖ}. Then gₖ conducts:

Step 1. Gather all local validation records of Bₖ₋₁ (as performed by Bₖ’s members). Step 2. Run a consistency check; if any transaction in Bₖ₋₁ is illegitimate,   * disable the offending nodes in Bₖ₋₁,   * disable any in Bₖ that validated them,   * report to genesis group for remediation. Step 3. If all clear, finalize confirmation:   * attach a single hash Hₖ = Hash(Hₖ₋₁ ∥ Txns(Bₖ₋₁)),   * timestamp Hₖ and broadcast to all previous box-geneses,   * boxer bₖ retains Hₖ as an immutable proof.

The affirmation “Bₖ₋₁ is closed and true” propagates recursively forward.

––––––––––––––––––––––––––––––––––––––––––––

4. Core Formulas and Security Guarantees

4.1 Tip‐Selection Rule To ensure freshness, nodes follow a rank‐based rule (Definition 2.2.2): letting r(v) be the DAG‐rank, any two successive validations vₖ → vₖ₊₁ must satisfy r(vₖ) ≤ r(vₖ₊₁) ≤ r(vₖ) + 1. Equivalently, if vₖ ∈ Bᵢ then vₖ₊₁ ∈ Bᵢ ∪ Bᵢ₊₁.

4.2 Random Box Size M M = F_X⁻¹(U), U∼Uniform(0,1).

4.3 Security: Probability of Double-Box Attack

Suppose an adversary wants to monopolize two consecutive boxes without other honest transactions arriving in 2τ. If honest transaction arrivals follow a Poisson process of rate λ, then

pₐₜₜₐcₖ = P(no honest arrivals in 2τ) = e^−2λτ.

For example, λ=30 tx/min, τ=20 s ≈1/3 min ⇒ pₐₜₜₐcₖ ≈ e^−2·30·1/3 ≈2×10⁻⁹.

With random selection of gₖ among multiple good nodes, overall takeover chance is essentially zero.

4.4 Hashing Structure

Let H₀ = Hash(“genesis”). Then for each closed box Bᵢ₋₁,

Hᵢ = H( Hᵢ₋₁ ∥ HashAll( Txns in Bᵢ₋₁ ) ).

Each boxer bᵢ and box-genesis gᵢ stores Hᵢ. Timestamps chain likewise, so any tampering breaks the chain of hash pointers.

––––––––––––––––––––––––––––––––––––––––––––

5. Boxer’s Contributions to Decentralization, Security and Efficiency

• Decentralization:  * Any “good-standing” node may become a boxer (and subsequently gᵢ), on each box. No dedicated miners or staking pools.  * Conditional randomization of M and τ prevents boxers from being pre-computed or monopolized.
• Security (“doubly-secure consensus”):  * 2 + 2 local recursion: each node in a box checks its immediate predecessor; boxer checks the entire in-box chain.  * Final global check by a randomly chosen box-genesis.  * Boxer retains the final hash and cross-checks with gᵢ → mutual oversight.  * Probability of contiguous takeover is provably negligible (Poisson‐arrival bound).
• Efficiency:  * No expensive Proof-of-Work (“mining”) — boxer selection is immediate upon criteria.  * Average finality time ≃1.5 τ (nodes wait at most 2τ before their box is closed and their parent box confirmed).  * Lightweight: boxer only stores hash pointers; gᵢ (full node) needs ledger copy.

In sum, the boxer node is the linchpin that (a) decides when an antichain is closed, (b) orchestrates the 2 + 2 in-box validations, (c) triggers the final box-genesis confirmation, and (d) secures the hash‐linked dual layer against forks and attacks — all in an open, randomized, fully decentralized fashion.