BlockGen: Multi-Domain Block Systems

• BlockGen is a term for systems that treat blocks as first-class objects, used in procedural 3D city generation, blockchain consensus, GPU event modeling, and blockwise sequence processing.
• In procedural 3D city generation, BlockGen uses a fine-tuned transformer with supervised and reinforcement learning to output editable, spatially-valid block programs with high format accuracy.
• Across domains—including blockchain and sequence modeling—BlockGen innovates by coupling decision-making processes (e.g., consensus or AR/diffusion sampling) directly with block generation for enhanced control and efficiency.

BlockGen is not a single standardized research object but a label used for several technically unrelated systems. In current arXiv literature it denotes a block-level LLM for procedural 3D city generation, a flexible blockwise discrete sequence model with hybrid samplers, a prototype GPU-oriented matrix-element engine for many-gluon amplitudes, and, in blockchain research, an abstracted architecture in which consensus itself generates transactions rather than merely recording them (Liu et al., 5 Feb 2026, Deschenaux et al., 1 Jun 2026, Bothmann et al., 2021, Zhang et al., 2024).

1. Research usages of the term

The term appears in multiple domains with different semantics and design goals.

Research area	Meaning of BlockGen	Primary object
Procedural 3D city generation	Block-level agent in CityGenAgent	Executable Block Program for urban layout
Blockchain systems	Generative blockchain abstraction	Consensus-coupled transaction generation
GPU event generation	Prototype matrix-element engine	Many-gluon tree amplitudes on GPUs
Discrete sequence modeling	Blockwise likelihood model	Hybrid AR/diffusion sequence generation

In related blockchain work, GraphChain is not itself named BlockGen, but it is explicitly presented as a redesign of how blocks are generated through graph structure and parallel mining; it therefore belongs to the same broader discourse on block-generation mechanisms (Kan et al., 2018).

2. BlockGen in procedural 3D city generation

Within CityGenAgent, BlockGen is the block-level agent that converts a natural-language block description $I$ into a structured, executable Block Program $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$. The overall city-generation problem is decomposed hierarchically: BlockGen handles where things go at block scale, while BuildingGen handles what each building looks like at facade-component level. A Block Program is a JSON-like list of elements with required id, type, and polygon fields, and optional building-only floor_count and facade fields. Polygons are specified in block coordinates as counter-clockwise, simple, non-self-intersecting footprints. The output is directly executable by a procedural executor and also supplies the semantic and spatial context for BuildingGen (Liu et al., 5 Feb 2026).

The representation is schema-constrained. The top level must be a list of objects; polygons must be simple and counter-clockwise; required fields must be present; and supervised training data reject overlapping polygons and layouts with too little or too much built area. These constraints are enforced offline during supervised fine-tuning and indirectly during reinforcement learning through rewards that favor spatially valid configurations.

Architecturally, BlockGen is a finetuned Qwen3-8B autoregressive transformer using LoRA with rank 8 on target modules. It is trained first by supervised fine-tuning on 5k synthetic prompt-program pairs and then by PPO-based reinforcement learning. The supervised stage teaches format accuracy and basic layout plausibility. The RL stage introduces a Spatial Alignment Reward built from four components: semantic alignment, global plausibility, geometric overlap, and footprint density. Semantic alignment and plausibility are scored by rendering the Block Program as a 2D top-down image and evaluating it against the text description with GPT-4o; overlap is computed from pairwise intersections of axis-aligned bounding boxes; density rewards layouts whose coverage lies in the target band $[0.5,0.8]$.

The reported ablation isolates the effect of this training pipeline. The untuned Qwen3-8B baseline has Collision $23.97\%$, Pos. $76.70$, and PSA $75.60$. After SFT, those become $5.59\%$, $80.17$, and $84.02$. DPO improves them slightly to $5.19\%$, $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$0, and $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$1, while PPO produces the best block-level results at $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$2, $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$3, and $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$4. In a broader comparison, CityGenAgent reports $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$5 format accuracy for BlockGen, compared with $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$6 for raw Qwen3-8B and $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$7 for GPT-4o and Qwen2.5-7B.

A central property of BlockGen is controllability. Because the model emits explicit polygons, type, floor_count, and facade fields, it supports natural-language editing of existing layouts: density can be increased on one side of a block, heights can be lowered near a park, or the style can be changed to a Chinese-style residential block. The paper notes, however, that several limitations remain at block level: spatial reasoning may degrade for very large or intricate layouts, collisions are reduced but not eliminated, the overlap metric uses bounding boxes rather than exact polygon intersection, road topology is not fully encoded, and the training data are synthetic rather than GIS-derived.

3. BlockGen in blockchain research

In blockchain research, BlockGen denotes a generative blockchain paradigm in which the consensus mechanism solves a business problem and thereby generates the transactions that it records. This departs from conventional ledgers, where transactions are produced off-chain and consensus only validates ordering and inclusion. The proposed architecture consists of users or clients posting problems, decentralized solvers producing candidate solutions, a consensus rule called Proof-of-Merit (PoM) selecting a winning solution, and a blockchain layer in which the winning solver writes a block containing the realized transactions implied by that solution. The merit signal is based on Total Utility Gain (TUG), i.e., normalized improvement over a benchmark solution, and winning chances are modulated over time by a post-winning adjustment and a Decentralized Control Parameter (DCP) that balances efficiency against decentralization (Zhang et al., 2024).

Formally, time is divided into problem-solving rounds, each solver proposes a solution $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$8, and the Winner Selection Score accumulates adjusted merit over time. The blockchain-specific novelty lies in coupling consensus to transaction generation itself: accepted parts of the winning solution become actual transactions, and the winning solver both realizes and records them. In the ridesharing instantiation, matchers propose one-to-one rider-driver assignments, riders accept or reject proposed matches, accepted matches are written into the next block, and the acceptance rate feeds back into future winning chances.

The agent-based simulation examines this design over 500 epochs of 1,500 rounds each, with 100 initial matchers per epoch, exogenous acceptance rate $P_{\text{block}} = \langle b_1,\ldots,b_n\rangle$9, DCP values from $[0.5,0.8]$0 to $[0.5,0.8]$1 in increments of $[0.5,0.8]$2, and matcher capabilities sampled from $[0.5,0.8]$3 for $[0.5,0.8]$4. The reported qualitative pattern is consistent across settings: increasing DCP raises inefficiency and lowers the Gini coefficient of wins, while increasing the number of steady-state solvers. The paper further states that, in the simulation settings, the number of steady-state solvers almost doubles as DCP rises from $[0.5,0.8]$5 to $[0.5,0.8]$6, and that the efficiency-equity frontier is nearly linear.

A different blockchain line of work addresses block generation through data structure and mining protocol rather than merit-based transaction generation. GraphChain replaces the linear chain with a graph in which each block represents a single transaction and contains the balance status of the traders. Transaction blocks usually have two inputs and two outputs, representing the previous and updated states of the two participating accounts. Leader election remains PoW-based, but elected leaders mine transaction blocks in parallel, and conflicts are resolved through Proof of Luck, in which the valid block is the one whose creator spends fewer retries. The paper uses a 10-minute election interval and 1-hour leader service time, yielding six simultaneous leaders in the example configuration, and reports that throughput rises with the number of leaders while multi-leader availability makes total downtime unlikely under its Gilbert-model analysis (Kan et al., 2018).

These two blockchain usages are distinct. The generative-blockchain BlockGen treats block creation as the endpoint of decentralized problem solving, whereas GraphChain treats block generation as a concurrency and data-structure problem. The shared theme is that block production is moved from passive recording toward an active computational mechanism.

4. BlockGen as a GPU-oriented event-generator prototype

In collider-physics software, BlockGen is the umbrella name for a prototype GPU-focused matrix-element engine rather than a full event generator. Its scope is deliberately narrow: tree-level, pure-gluon QCD processes, with no loops, no quarks, no electroweak particles, no PDFs, and no hadronization. The purpose is to study algorithmic scaling on modern GPUs and to establish baseline implementations for future simulation programs. The code base includes leading-color GPU codes, full-color color-ordered variants with explicit color summation or color-flow sampling, and a full-color color-dressed implementation with continuous color polarizations (Bothmann et al., 2021).

The theoretical backbone is Berends–Giele recursion. The paper studies color-ordered Berends–Giele (COBG) recursion, color-dressed Berends–Giele (CDBG) recursion in the color-flow basis, and different strategies for helicity sums, helicity sampling, explicit color sums, and color sampling. A key complexity contrast is that COBG requires $[0.5,0.8]$7 partial amplitudes and, for full color, a precomputable color matrix whose summation scales as $[0.5,0.8]$8, whereas CDBG integrates color into the recursion and scales roughly like $[0.5,0.8]$9 in the number of currents. On GPUs, this changes the bottlenecks: arithmetic cost matters, but memory footprint and bandwidth often dominate.

The implementation primarily uses event-level parallelization: each GPU thread or thread block processes an independent phase-space point, and the recursion is executed serially within that event. The authors explicitly compare this design to a more complex event-plus-recursion-level parallelization and conclude that, on a modern NVIDIA V100, pure event-level parallelization is sufficient. Memory layout is central. Global memory stores input momenta, output weights, color matrices for the color-summed COBG case, and dressed currents for CDBG. Shared memory is used selectively in some variants, and real-valued formulations based on continuous helicity and color sampling are emphasized because they halve per-object memory relative to complex-valued implementations.

The reported performance picture is highly regime-dependent. COBG with explicit color summation is very fast at low multiplicity and competitive up to about $23.97\%$0, but its scaling deteriorates because the color matrix becomes dominant and exceeds $23.97\%$1 for $23.97\%$2. COBG with color-flow sampling scales better. CDBG with continuous color has the worst absolute performance at low multiplicity but much more favorable asymptotic scaling and becomes competitive only for $23.97\%$3. In GPU-versus-CPU comparisons, for $23.97\%$4 the best GPU algorithm is at least an order of magnitude faster per event than CPU counterparts; after hardware and representation adjustments, the authors estimate that a factor of about $23.97\%$5 in favor of the GPU remains. At $23.97\%$6, GPU COBG and CPU Comix or Amegic perform similarly.

The practical recommendation is correspondingly hybrid. For low to medium multiplicities, the preferred GPU strategy is color-ordered recursion with explicit color summation; for high multiplicities, the recommendation is color-dressed recursion with color sampling. The broader significance is methodological: BlockGen is presented as groundwork for GPU-native event generators that exploit KV-like reuse at the workload level through event parallelism and hardware-conscious recursion design.

5. BlockGen as blockwise sequence modeling

In discrete sequence modeling, BlockGen is a likelihood-based blockwise model that interpolates between pure autoregressive language modeling and block diffusion. For a fixed block size $23.97\%$7, the sequence density factorizes over contiguous blocks,

$23.97\%$8

where each conditional is implemented by a diffusion process that corrupts and denoises only the current block while conditioning on an uncorrupted prefix. BlockGen generalizes this by mixing several block sizes,

$23.97\%$9

so that block size $76.70$0 recovers a standard AR model and larger block sizes produce block diffusion models. A single shared denoiser backbone is used across block sizes, with the block size provided as input (Deschenaux et al., 1 Jun 2026).

The framework supports both masked diffusion models (MDMs) and uniform-state diffusion models (USDMs). Both use the same interpolating corruption process,

$76.70$1

but they differ in the prior $76.70$2: MDMs use a one-hot mask token and therefore make masking absorbing, while USDMs use the uniform distribution over the vocabulary and therefore allow tokens to jump between all states throughout the reverse chain. This gives USDMs intrinsic revisiting ability under ancestral sampling, whereas MDMs require explicit correctors to reconsider earlier token choices.

The signature sampling contribution is AR-informed predictor-corrector sampling (ARPC). A diffusion predictor first proposes clean block tokens. The same shared model is then run in AR mode with block size $76.70$3, producing per-token AR probabilities for the proposal. Tokens with the lowest AR log-likelihood are re-noised and re-generated. Because the verifier is simply the same denoiser executed under a different factorization, ARPC requires no auxiliary verifier network. The paper also defines entropy-informed predictor-corrector (EIPC), which uses the diffusion model’s own token entropy rather than AR scoring.

The empirical comparison is nuanced. Under ancestral sampling in the block-by-block setting, uniform diffusion outperforms masked diffusion, especially in the few-step regime. On GSM8K with block size $76.70$4 and temperature $76.70$5, the reported accuracies are $76.70$6 for masked versus $76.70$7 for uniform at NFE $76.70$8, $76.70$9 versus $75.60$0 at NFE $75.60$1, and $75.60$2 versus $75.60$3 at NFE $75.60$4. On OpenWebText, single-block ancestral uniform BDMs also yield lower Generative Perplexity than masked BDMs at the same entropy for all tested NFE budgets.

Under ARPC, however, the ranking changes. The paper reports that the gap closes and reverses at high NFE: for block size $75.60$5, MDMs reach slightly higher GSM8K accuracy than USDMs, and a similar reversal appears in Generative Perplexity on OpenWebText. This produces the paper’s central conclusion: uniform dominates masked under ancestral sampling, but with an informed corrector that uses AR scoring, masked diffusion can match or slightly surpass uniform diffusion in the high-NFE regime.

Training results reinforce the interpolation claim. On OpenWebText after 1M steps, the AR Transformer baseline reaches validation perplexity $75.60$6. The best single-block masked BDM with $75.60$7 reaches $75.60$8, while BlockGen trained on block sizes $75.60$9 with uniform mixture weights $5.59\%$0 reaches $5.59\%$1 in the masked case and $5.59\%$2 in the uniform case. The shared architecture is a 12-layer Transformer with hidden dimension $5.59\%$3, $5.59\%$4 heads, and a time-unconditional denoiser, chosen partly to preserve cacheability across steps and across block sizes.

6. Conceptual relations and disambiguation

The literature does not present BlockGen as a unified framework. Rather, the name is attached to several unrelated technical programs: a city-block layout generator, a blockchain architecture in which consensus generates transactions, a GPU matrix-element prototype, and a blockwise AR/diffusion sequence model (Liu et al., 5 Feb 2026, Zhang et al., 2024, Bothmann et al., 2021, Deschenaux et al., 1 Jun 2026). A common misconception is therefore that BlockGen refers to one canonical software stack or one stable research lineage; the current record does not support that interpretation.

This suggests a looser family resemblance centered on structured intermediate units. In CityGenAgent, the unit is the city block and its executable Block Program. In generative blockchain, the unit is the consensus round whose solution determines a block’s transaction content. In sequence modeling, the unit is the token block that mediates between left-to-right factorization and diffusion-style parallel refinement. In the GPU event-generator work, the name is more project-specific, but the technical emphasis is again on blockwise decomposition of a larger computational problem. A plausible implication is that the recurrence of the term reflects a preference for mesoscopic structure—between atomic tokens or transactions and full global objects—rather than any shared algorithmic doctrine.

Across these usages, the most concrete contrast is between explicit structure and implicit generation. CityGenAgent’s BlockGen outputs editable polygons and fields. The blockchain formulations make transaction realization itself part of the consensus protocol or part of a graph-structured block-generation process. The sequence-modeling BlockGen exposes block size as a control variable in the likelihood and in the sampler. The event-generator BlockGen compares recursion schemes whose feasibility is determined by memory layout and scaling. The name is therefore best understood as a domain-dependent label for systems that make “blocks” first-class computational objects, but not as a single concept with uniform semantics.