LB-Louvain: Balancing Transaction Locality and Shard Load in Account-Based State Sharding

Featured Application

The proposed method supports adaptive account placement in sharded blockchain systems by coordinating transaction locality with processing-load balance across physical shards.

Abstract

Account-based state sharding improves blockchain parallelism by distributing account states and transaction execution across physical shards, but effective placement must preserve transaction locality without concentrating processing demand on a small number of shards. This paper presents LB-Louvain, a coarse-to-fine account-partitioning heuristic in which standard Louvain first extracts logical communities, followed by load-aware community-to-shard assignment and restricted boundary-account refinement. In controlled BlockEmulator experiments using 300,000 replayed Ethereum transactions and five repeated system runs per configuration, relative to CLPA, the complete LB-Louvain pipeline reduces the mean cross-shard transaction ratio by approximately 2.1%, increases active throughput by approximately 19.7%, and reduces average confirmation latency by approximately 9.4%. Component-wise ablation confirms complementary roles for load-aware assignment and boundary refinement. The evaluated behavior remains stable over $\beta \in [1,4]$, while partition-only profiling keeps the measured partition computation below 100 ms across the tested 50,000–300,000 transaction prefixes and 4–24 physical shards. An auxiliary migration experiment further shows that Fine-Grained activation reduces the observed migration-deferred set by approximately 39.8% relative to Full Locking while maintaining comparable throughput and confirmation latency. Broader archived experiments with Monoxide and CLPA are retained separately from the controlled revision results.

1. Introduction

Blockchain systems require full nodes to validate transactions, execute state transitions, and maintain a replicated ledger. This replication supports decentralized verification, but causes communication, storage, and computation costs to grow with workload [1]. Sharding addresses this bottleneck by dividing network participants, transaction processing, or ledger state among multiple shards operating in parallel [1]. Existing systems apply sharding to different objects: OmniLedger [2] and RapidChain [3] divide network or transaction processing, whereas Chainspace [4] and Monoxide [5] partition objects or account state. This paper focuses on account-based state sharding, in which each account state is assigned to one physical shard. Because the account-to-shard mapping determines both state ownership and transaction routing, effective account placement is essential for exploiting shard-level parallelism without creating persistent workload concentration.

In account-based state sharding, the account-to-shard mapping determines state ownership, transaction routing, and the placement of processing demand. This paper considers the relay-based cross-shard execution model exemplified by Monoxide [5], because a transfer whose sender and recipient reside on different shards requires processing at both participating shards. As shown in Figure 1, the source shard first processes the sender-side update and generates a relay transaction, which is then delivered to the destination shard for verification and recipient-side state update. By contrast, an intra-shard transfer is completed within a single shard.

Account placement therefore directly affects both transaction locality and shard-load distribution. Here, transaction locality means placing frequently interacting accounts in the same shard so that more observed transfers can be processed without cross-shard relaying. This creates a natural tradeoff: grouping active accounts improves locality but may concentrate processing demand on a few shards, whereas dispersing them improves load balance but can increase cross-shard transfers.

Existing studies address this tradeoff mainly through two directions. One direction changes the allocation unit: BrokerChain [6] segments account state and introduces broker accounts to reduce cross-shard processing and workload skew, while Estuary [7] uses state splitting. The other direction exploits transaction relations for graph-based placement. Transformers [8] formulate cross-shard transactions and workload balance as a network-partitioning problem. TxAllo [9] dynamically allocates accounts and transactions under throughput and workload considerations. Han et al. [10] incorporate temporal interaction patterns, whereas Yin et al. [11] consider workload-constrained graph partitioning. ShardCutter [12] further combines community-aware partitioning with account migration. These methods demonstrate the importance of considering locality and load jointly. However, in community-based placement, the number, size, and activity of detected communities are determined by graph structure rather than the configured physical-shard set [13]. Logical communities must therefore still be mapped onto physical shards, and heterogeneous community activity can leave residual load concentration after coarse placement.

To address this challenge, LB-Louvain adopts a coarse-to-fine account-partitioning strategy. Historical Ethereum transfers are aggregated into an undirected weighted account graph, and standard Louvain [13] extracts logical communities with dense observed interactions. LB-Louvain then performs load-aware community-to-shard assignment to disperse highly active communities across physical shards, followed by restricted boundary-account rebalancing to alleviate residual hotspots. The two stages operate at different granularities: community-level placement controls coarse load concentration, while boundary-level adjustment provides fine-grained correction without discarding the interaction structure captured by Louvain.

The main contributions are as follows:

1.

A fixed-shard account-placement formulation that explicitly captures the tradeoff between historical transaction locality and shard-load balance while preserving unique account-to-shard ownership;

2.

LB-Louvain, which addresses this tradeoff through load-aware community-to-shard assignment and restricted boundary-account rebalancing while using standard Louvain to preserve coarse interaction structure;

3.

A multi-level empirical evaluation combining controlled component-wise ablation, parameter and repartitioning-cadence sensitivity, partition-runtime and allocation profiling, and auxiliary migration–activation measurements with broader archived end-to-end comparisons against Monoxide and CLPA.

Under the controlled 300,000-transaction configuration, relative to CLPA, the complete LB-Louvain pipeline reduces the mean cross-shard transaction ratio by approximately 2.1%, increases active throughput by approximately 19.7%, and reduces average confirmation latency by approximately 9.4%. The component-wise ablation confirms complementary roles for load-aware community assignment and boundary-account refinement, while the sensitivity and profiling experiments show stable evaluated behavior over $\beta \in [1,4]$ and low partitioning overhead across the tested transaction-prefix and shard-count configurations. The broader end-to-end and migration experiments further show that these partitioning improvements remain effective across different operating conditions and can be applied while limiting transaction disruption during reconfiguration.

The remainder of this paper is organized as follows. Section 2 reviews related account-placement and reconfiguration work. Section 3 defines the account-partitioning problem and its evaluation criteria. Section 4 describes LB-Louvain. Section 5 reports the experimental evaluation and discussion, and Section 6 concludes the paper.

2. Related Work

To examine account placement under the locality–load tradeoff, this section reviews existing work from two perspectives: the definition of the placement unit and the use of transaction or workload information to guide placement. Account-placement methods differ chiefly in allocation unit and workload information. Monoxide [5] maps account addresses through deterministic bits, enabling simple location lookup but not adapting to observed transaction relationships. BrokerChain [6] changes the placement unit through account segmentation and broker-assisted execution, while Estuary [7] splits account state and ABChain [14] combines balanced partitioning with adaptive brokers. These approaches reduce cross-shard processing through deterministic placement, broker assistance, or state splitting, but they differ in whether complete accounts remain the basic placement unit. LB-Louvain retains complete accounts and changes only their physical-shard assignments according to observed transaction activity.

Graph-based methods use transaction history to guide account allocation and are therefore the closest to the setting considered in this work. Transformers [8], whose community-aware partitioning method is used as the CLPA baseline in our evaluation, formulates cross-shard activity and workload balance as a network-partitioning problem. TxAllo [9] dynamically allocates accounts and transactions while jointly considering throughput, cross-shard activity, and workload balance. Han et al. [10] model historical interactions with a transaction hypergraph, whereas Yin et al. [11] impose shard-workload constraints on graph-based state partitioning. ShardCutter [12] further integrates community-aware partitioning with state migration. These studies establish transaction locality and workload balance as two closely coupled objectives and motivate a placement mechanism that coordinates them when logical communities must be mapped onto a fixed set of physical shards.

Standard Louvain produces logical communities whose number, size, and activity are determined by graph structure rather than by a prescribed physical-shard count [13]. Consequently, community detection alone does not determine how the extracted communities should be placed on a fixed set of physical shards, while heterogeneous community activity may still produce workload concentration after coarse placement. This leads to a specific placement problem: how to preserve the coarse interaction structure captured by community detection while distributing processing demand across the configured physical shards. LB-Louvain addresses this problem through a coarse-to-fine design that retains logical communities as locality-preserving placement units, assigns them to physical shards according to estimated shard load, and then restricts account-level correction to boundary accounts associated with observed cross-shard relationships. The component-wise evaluation in Section 5 isolates the effects of these two proposed refinement stages.

Other systems optimize adjacent placement and reconfiguration decisions. OptChain [15] performs online transaction placement, Shard Scheduler [16] jointly controls object placement and migration, and LB-Chain [17] performs load-driven account migration. Tao et al. [18] organize dynamic shards around smart contracts and use inter-shard merging to reduce cross-shard communication. Meepo [19] and Aeolus [20] focus on permissioned state execution, while SkyChain [21] and MetaShard [22] operate as broader system-level sharding controllers. These studies demonstrate that sharding performance can be improved at multiple control levels, but their decision variables differ from fixed-shard placement of complete accounts. For community-based account partitioning, standard Louvain [13] returns logical communities according to graph structure; neither the number nor the activity of these communities is constrained by the configured physical-shard set. Directly using community labels as shard identifiers can therefore leave shards underused or concentrate active communities, whereas unrestricted account-level reassignment can weaken the coarse interaction structure. This motivates separating logical-community extraction from physical-shard placement and retaining limited boundary-level adjustment for residual load concentration.

When an account-to-shard mapping changes, the corresponding state must be relocated before the new mapping can take effect. tMPT [23] studies cross-shard reconfiguration through a trimmed Merkle Patricia Trie, while the fine-tuned lock mechanism [24] reduces blocking during account migration. These studies complement account-placement methods by addressing the activation of an already determined mapping. Section 3 next formalizes the account-partitioning problem and its evaluation criteria.

3. Account-Partitioning Problem Definition

This section defines the account-partitioning problem addressed by LB-Louvain. Recent transaction activity is represented as a weighted account graph, from which transaction locality and shard load are measured.

3.1. Account Mapping and Transaction Classification

Let $V=\{v_1,v_2,\dots ,v_N\}$ denote the account set and $S=\{s_1,s_2,\dots ,s_K\}$ the fixed set of physical shards. An account-to-shard mapping P assigns each account to one physical shard. For shard $s_k$, its account set $V_k$ is defined as

$$P:V\to S,V_k=\{v_i\in V\mid P\left(v_i\right)=s_k\}.$$

(1)

Under the mapping in Equation (1), each account belongs to exactly one physical shard.

A transfer transaction is denoted by $tx=(v_i,v_j)$, where $v_i$ and $v_j$ are the sender and recipient, respectively. Its type under mapping P is defined as

$$\mathrm{type}\left(tx\right)=\left\{\begin{array}{cc}\mathrm{intra},\hfill & P\left(v_i\right)=P\left(v_j\right),\hfill \\ \mathrm{cross},\hfill & P\left(v_i\right)\ne P\left(v_j\right).\hfill \end{array}\right.$$

(2)

According to Equation (2), whether a transaction is intra-shard or cross-shard depends on the account mapping. An intra-shard transaction is processed within one shard, whereas a relay-based cross-shard transaction involves processing at both the source and destination shards [5]. This distinction is used below to assign different load contributions to the two transaction types.

3.2. Weighted Account Transaction Graph

Let $T^H$ denote the set of transactions observed during the current historical partitioning window. LB-Louvain treats $T^H$ as a retrospective workload signal: the graph, locality metric, and shard-load estimates characterize the interactions observed in that window and do not predict future transaction activity. The historical window is assumed to contain at least one transaction. Accounts that first appear in a later window contribute to the reconstructed interaction graph only from the first window in which they are observed; no future activity is inferred before that observation. These transactions are aggregated into an undirected weighted account transaction graph $G=(V,E,W)$. An edge $e_{ij}=(v_i,v_j)$ exists when at least one transaction between $v_i$ and $v_j$ appears in $T^H$. Let $T_{ij}^H$ denote the corresponding transaction subset. The graph and edge weights are defined as

$$\begin{array}{cc}\hfill G& =(V,E,W),\hfill \\ \hfill E& =\{(v_i,v_j)\mid \left|T_{ij}^H\right|>0\},\hfill \\ \hfill w_{ij}& =\left|T_{ij}^H\right|.\hfill \end{array}$$

(3)

In Equation (3), the set W contains all edge weights. Each original transfer retains a sender and a recipient during execution, but the partitioning graph deliberately aggregates the two directions of an account pair into a single undirected weight $w_{ij}$. The resulting weight therefore represents historical interaction frequency rather than a directional traffic rate. This representation is consistent with the locality objective introduced below, for which placing two frequently interacting accounts on the same shard removes relay processing regardless of which endpoint acted as sender in an individual transfer.

The undirected representation does not imply that sender and recipient roles are interchangeable during execution. Direction-specific access roles and asymmetric sender/recipient behavior are not modeled explicitly by the current partitioning graph; instead, their observed interaction volume is collapsed into the pairwise weight used for community extraction and placement. Extending the load model to a directed or role-aware transaction graph would require reformulating the graph statistics and the corresponding placement cost, and is therefore left outside the present method. The resulting weighted graph provides the input representation used by the account-partitioning procedure in Section 4.

3.3. Partitioning Metrics and Problem Statement

Let $x_{ik}$ be a binary assignment variable indicating whether account $v_i$ is assigned to shard $s_k$:

$$\begin{array}{c}{x}_{ik}=\left\{\begin{array}{cc}1,\hfill & P\left(v_i\right)=s_k,\hfill \\ 0,\hfill & P\left(v_i\right)\ne s_k,\hfill \end{array}\right.\\ {\displaystyle \sum _{k=1}^K}{x}_{ik}=1,x_{ik}\in \{0,1\},\forall v_i\in V.\end{array}$$

(4)

Equation (4) ensures that no account is unassigned or simultaneously assigned to multiple physical shards.

Under mapping P, the weighted number of cross-shard transactions and the corresponding cross-shard transaction ratio are

$$\begin{array}{cc}\hfill C\left(P\right)& =\sum _{(v_i,v_j)\in E}{w}_{ij}\mathbb{I}\left[P\left(v_i\right)\ne P\left(v_j\right)\right],\hfill \\ \hfill \mathrm{CTR}\left(P\right)& ={\displaystyle \frac{C\left(P\right)}{{\sum }_{(v_i,v_j)\in E}{w}_{ij}}}.\hfill \end{array}$$

(5)

In Equation (5), $\mathbb{I}[·]$ is the indicator function. $C\left(P\right)$ accumulates the weights of the transaction edges cut by the mapping, while $\mathrm{CTR}\left(P\right)$ normalizes this quantity by the total observed transaction weight. A smaller $\mathrm{CTR}\left(P\right)$ indicates that more historical transactions can be processed within individual shards.

To distinguish the processing costs of intra-shard and cross-shard transactions, the two types of load are calculated separately. For shard $s_k$, the intra-shard load and cross-shard load are defined as

$$\begin{array}{cc}\hfill {\mathrm{In}}_k\left(P\right)& =\sum _{(v_i,v_j)\in E}{w}_{ij}\mathbb{I}\left[P\left(v_i\right)=s_k\wedge P\left(v_j\right)=s_k\right],\hfill \\ \hfill {\mathrm{Ex}}_k\left(P\right)& =\sum _{(v_i,v_j)\in E}{w}_{ij}\hfill \\ \hfill & ·\mathbb{I}\left[\begin{array}{c}(P\left(v_i\right)=s_k\wedge P\left(v_j\right)\ne s_k)\hfill \\ \vee (P\left(v_j\right)=s_k\wedge P\left(v_i\right)\ne s_k)\hfill \end{array}\right].\hfill \end{array}$$

(6)

After the two load components are defined in Equation (6), the estimated load of shard $s_k$ and the average shard load are defined as

$$\begin{array}{cc}\hfill L_k\left(P\right)& ={\mathrm{In}}_k\left(P\right)+\beta {\mathrm{Ex}}_k\left(P\right),\hfill \\ \hfill \overline{L}\left(P\right)& ={\displaystyle \frac{1}{K}}{\displaystyle \sum _{k=1}^K}{L}_k\left(P\right).\hfill \end{array}$$

(7)

In Equation (7), $\beta >0$ is the cross-shard load coefficient used to weight the relative processing contribution of cross-shard transactions in the shard-load estimate. An intra-shard edge of weight $w_{ij}$ contributes $w_{ij}$ to the load of the shard containing both endpoints, whereas a cross-shard edge contributes $\beta w_{ij}$ to each of its two participating shards through ${\mathrm{Ex}}_k\left(P\right)$. Thus, when shard loads are aggregated, a cross-shard edge contributes $2\beta w_{ij}$, while an intra-shard edge contributes $w_{ij}$. The coefficient $\beta$ is an implementation-level relative cost weight rather than an independently measured network-delay or hardware-cost ratio. Unless varied explicitly, the controlled experiments use $\beta =2.0$, and Section 5.3 evaluates sensitivity over $\beta \in \{1.0,1.5,2.0,3.0,4.0\}$.

Shard-load imbalance is characterized by   

$$\begin{array}{cc}\hfill D\left(P\right)& =\sqrt{{\displaystyle \frac{1}{K}}\sum _{k=1}^K{\left[L_k\left(P\right)-\overline{L}\left(P\right)\right]}^2},\hfill \\ \hfill L_{\max }\left(P\right)& =\underset{1\le k\le K}{\max }{L}_k\left(P\right).\hfill \end{array}$$

(8)

In Equation (8), $D\left(P\right)$ measures load dispersion across all physical shards, whereas $L_{\max }\left(P\right)$ identifies the shard with the highest estimated load. The normalized load dispersion $D\left(P\right)/\overline{L}\left(P\right)$ avoids direct dependence on the overall transaction volume, while $L_{\max }\left(P\right)$ serves as a complementary indicator of hot-shard concentration.

The quality of a feasible account mapping is characterized by the following criterion vector:

$$\begin{array}{cc}\hfill J\left(P\right)& =\left(\mathrm{CTR}\left(P\right),{\displaystyle \frac{D\left(P\right)}{\overline{L}\left(P\right)}}\right),\hfill \\ \hfill P& \in \mathcal{F},\hfill \\ \hfill \mathcal{F}& =\{P:V\to S\mid P\mathrm{satisfies}(4\left)\right\}.\hfill \end{array}$$

(9)

For the criterion vector in Equation (9), smaller values of the first and second components indicate better historical transaction locality and a more balanced shard-load distribution, respectively.

4. LB-Louvain: Load-Balanced Account Partitioning

4.1. Design Overview

This section presents LB-Louvain, which transforms the weighted account transaction graph defined in Section 3 into a feasible account-to-shard mapping. Equation (9) evaluates feasible mappings using transaction locality and normalized shard-load dispersion. Exhaustively examining account-level assignments is impractical: mapping N accounts to K shards yields $K^N$ candidate mappings, while changing an assignment may improve one criterion but worsen the other. Using a fixed weighted sum of the two criteria in $J\left(P\right)$ would also require choosing an additional cross-objective tradeoff coefficient in advance.

LB-Louvain therefore reduces the decision granularity step by step. First, standard Louvain groups accounts with dense weighted interactions, preserving high-frequency relations at the community level. However, the number and activity of communities need not match the K physical shards, so the second stage assigns communities according to current shard loads. Keeping communities intact preserves their internal interaction structure but can leave residual hotspots; therefore, the third stage considers only boundary accounts and accepts movements that reduce the local source–destination maximum load. Community extraction thus supports the locality criterion in (9), while load-aware placement and restricted refinement provide tractable decisions for improving shard-load balance.

Figure 2 summarizes the procedure: the historical transaction graph is converted into logical communities, the communities are mapped to physical shards in nonincreasing activity order, and boundary accounts are then examined for load-reducing movements to obtain the target mapping $P^{\mathrm{new}}$.

4.2. Louvain-Based Community Extraction

The first stage applies standard Louvain to the weighted account graph $G=(V,E,W)$. Each account initially forms an individual community. Louvain then groups accounts whose weighted transaction relationships are denser within communities than expected under a degree-preserving baseline. Following Blondel et al. [13], the modularity of the undirected weighted graph defined in (3) is given by   

$$\begin{array}{c}Q={\displaystyle \frac{1}{2m}\sum _{v_i,v_j\in V}}\left(w_{ij}-{\displaystyle \frac{d_i{d}_j}{2m}}\right)\delta (c_i,c_j),\\ d_i={\displaystyle \sum _{v_j\in V}}{w}_{ij},2m={\displaystyle \sum _{v_i\in V}}{d}_i.\end{array}$$

(10)

In Equation (10), $w_{ij}=0$ when $(v_i,v_j)\notin E$, $d_i$ is the weighted degree of account $v_i$, $c_i$ is its community label, and $\delta (c_i,c_j)$ equals one when $v_i$ and $v_j$ have the same community label and zero otherwise. LB-Louvain adopts this standard modularity objective without changing the internal local-moving or community-aggregation rules of Louvain.

During local moving, an account is tentatively assigned to its neighboring communities, and the movement producing the largest positive modularity gain is retained. When no further positive movement is available, the accounts belonging to the same community are aggregated into a supernode. The local-moving and aggregation operations are repeated until further aggregation no longer increases modularity.

The resulting logical-community set is

$$\begin{array}{c}\mathcal{C}=\{{\mathcal{C}}_1,{\mathcal{C}}_2,\dots ,{\mathcal{C}}_R\},{\displaystyle \bigcup _{r=1}^R}{\mathcal{C}}_r=V,\\ {\mathcal{C}}_a\cap {\mathcal{C}}_b=⌀\mathrm{for}a\ne b.\end{array}$$

(11)

In Equation (11), R is determined by the transaction graph and generally differs from the number K of physical shards. Consequently, the community labels cannot be used directly as physical-shard identifiers. A separate community-to-shard assignment is required to transform the logical communities into a valid account mapping.

The modularity objective primarily captures transaction locality and does not directly optimize shard-load distribution. Therefore, standard Louvain is used only for logical-community extraction, while load-aware physical placement is performed in the following stage.

4.3. Load-Aware Community-to-Shard Assignment

The second stage treats each detected community as an indivisible coarse-grained placement unit. A community-to-shard mapping $\varphi :\mathcal{C}\to S$ is constructed, allowing multiple logical communities to be assigned to the same physical shard. Keeping communities intact during this stage avoids prematurely separating accounts whose historical transaction relationships have been identified as locally dense.

Let $\mathsf{\ell }\left({\mathcal{C}}_r\right)$ denote the weighted activity of community ${\mathcal{C}}_r$. It is calculated from the weighted degrees of its accounts. The communities are processed in nonincreasing activity order:   

$$\begin{array}{c}\mathsf{\ell }\left({\mathcal{C}}_r\right)={\displaystyle \sum _{v_i\in {\mathcal{C}}_r}}{d}_i,\\ \mathsf{\ell }\left({\mathcal{C}}_{\left(1\right)}\right)\ge \mathsf{\ell }\left({\mathcal{C}}_{\left(2\right)}\right)\ge \cdots \ge \mathsf{\ell }\left({\mathcal{C}}_{\left(R\right)}\right).\end{array}$$

(12)

The activity estimate in (12) is used only to determine the processing order. It is independent of physical-shard placement and therefore does not classify an inter-community edge as a cross-shard edge before the endpoint communities have been assigned. The actual shard loads are calculated using the different intra-shard and cross-shard contributions defined in (6) and (7).

Processing highly active communities first reduces the possibility that several large communities will be concentrated on the same physical shard. Let

$$q=\min (R,K).$$

The first q communities are assigned to different physical shards. If $R<K$, each community is assigned to one shard and the remaining shards are temporarily empty. If $R\ge K$, the first K communities are used to initialize the K physical shards.

Let ${\widehat{L}}_k$ denote the current estimated load maintained for shard $s_k$ during sequential community placement. After the initial assignment, each remaining community is mapped to the currently least-loaded shard:

$$\varphi \left({\mathcal{C}}_{\left(r\right)}\right)\in \underset{s_k\in S}{\arg \min }{\widehat{L}}_k,r>q.$$

(13)

For the placement rule in Equation (13), ties among equally loaded candidate shards are resolved under the deterministic execution mode used in the experiments, without introducing an additional optimization objective. Therefore, the selected mapping may depend on the deterministic community-processing order and tie resolution when multiple placements satisfy the same least-loaded-shard criterion; uniqueness of the resulting mapping is not claimed. After community ${\mathcal{C}}_{\left(r\right)}$ is assigned, the affected intra-shard load ${\mathrm{In}}_k$, cross-shard load ${\mathrm{Ex}}_k$, and total load $L_k$ are updated according to (6) and (7).

Inter-community transaction relationships are retained during this update. When the endpoint communities of an inter-community edge are assigned to the same physical shard, the edge weight contributes to the corresponding intra-shard load. When they are assigned to different physical shards, the edge weight contributes to the cross-shard load of each involved shard. Edges involving an unassigned community are incorporated once the placements of both endpoint communities become known. Therefore, the assignment procedure accounts for the processing of a cross-shard transaction at both participating shards.

The community assignment is expanded into the initial account mapping as

$$P^{\left(0\right)}\left(v_i\right)=\varphi \left({\mathcal{C}}_r\right),\forall v_i\in {\mathcal{C}}_r,{\mathcal{C}}_r\in \mathcal{C}.$$

(14)

The mapping in Equation (14) expands the community assignment to all accounts. Because the communities in (11) form a disjoint partition of V, the resulting mapping $P^{\left(0\right)}$ satisfies the unique-assignment constraint in (4).

Algorithm 1 disperses highly active communities before assigning the remaining communities to currently lighter shards. However, because every community remains intact during coarse-grained placement, a single highly active community or the accumulated load of several communities may still produce a residual hotspot. The initial mapping $P^{\left(0\right)}$ is therefore passed to boundary-account rebalancing.

Algorithm 1 Load-Aware Community-to-Shard Assignment

Input: Weighted graph $G=(V,E,W)$; community set $\mathcal{C}=\{{\mathcal{C}}_1,\dots ,{\mathcal{C}}_R\}$; physical-shard set $S=\{s_1,\dots ,s_K\}$.

Output: Initial mapping $P^{\left(0\right)}$; estimated shard loads $\{{\widehat{L}}_1,\dots ,{\widehat{L}}_K\}$.

1: Compute $\mathsf{\ell }\left({\mathcal{C}}_r\right)$ for every ${\mathcal{C}}_r\in \mathcal{C}$.

2: Order ${\mathcal{C}}_{\left(1\right)},\dots ,{\mathcal{C}}_{\left(R\right)}$ according to (12).

3: Set $P^{\left(0\right)}\left(v_i\right)$ as undefined for every $v_i\in V$.

4: for each $s_k\in S$, initialize $V_k\leftarrow ⌀$, ${\mathrm{In}}_k\leftarrow 0$, ${\mathrm{Ex}}_k\leftarrow 0$, and ${\widehat{L}}_k\leftarrow 0$.

5: Set $q\leftarrow \min (R,K)$.

6: for $r\leftarrow 1$ to q do

7:     $\varphi \left({\mathcal{C}}_{\left(r\right)}\right)\leftarrow s_r$.

8:     Set $P^{\left(0\right)}\left(v_i\right)\leftarrow s_r$ for every $v_i\in {\mathcal{C}}_{\left(r\right)}$.

9:     Update affected ${\mathrm{In}}_k$, ${\mathrm{Ex}}_k$, and ${\widehat{L}}_k$ using (6) and (7).

10: end for.

11: for $r\leftarrow q+1$ to R do

12:     Select $s_k\in \arg {\min }_{s_j\in S}{\widehat{L}}_j$.

13:     $\varphi \left({\mathcal{C}}_{\left(r\right)}\right)\leftarrow s_k$.

14:     Set $P^{\left(0\right)}\left(v_i\right)\leftarrow s_k$ for every $v_i\in {\mathcal{C}}_{\left(r\right)}$.

15:    Update affected ${\mathrm{In}}_k$, ${\mathrm{Ex}}_k$, and ${\widehat{L}}_k$ using (6) and (7).

16: end for.

17: return $P^{\left(0\right)}$ and $\{{\widehat{L}}_1,\dots ,{\widehat{L}}_K\}$.

4.4. Boundary-Account Rebalancing

The third stage performs restricted account-level refinement. It considers only accounts whose transaction neighbors are distributed across different physical shards. This restriction provides finer load-adjustment capability without allowing arbitrary movements to unrelated shards.

For account $v_i$, let $\mathcal{N}\left(v_i\right)$ denote its transaction neighbors. The boundary-account set under mapping P is

$$\begin{array}{cc}\hfill \mathcal{N}\left(v_i\right)& =\{v_j\in V\mid (v_i,v_j)\in E\},\hfill \\ \hfill \mathcal{B}\left(P\right)& =\{v_i\in V\mid \exists v_j\in \mathcal{N}\left(v_i\right),P\left(v_j\right)\ne P\left(v_i\right)\}.\hfill \end{array}$$

(15)

The boundary set in Equation (15) depends on the current mapping and may change after an accepted movement. For each $v_i\in \mathcal{B}\left(P\right)$, candidate destinations are restricted to the distinct shards hosting its external neighbors:

$$\begin{array}{cc}\hfill {\mathcal{N}}_S(v_i;P)=\{P\left(v_j\right)\in S\mid & v_j\in \mathcal{N}\left(v_i\right),\hfill \\ \hfill & P\left(v_j\right)\ne P\left(v_i\right)\}.\hfill \end{array}$$

(16)

The restriction in Equation (16) ensures that each candidate shard has an observed transaction relationship with $v_i$. Moving an account to an unrelated shard is not considered because such a movement has no locality basis and may unnecessarily increase cross-shard processing.

Suppose $v_i$ currently belongs to source shard $s_a=P\left(v_i\right)$, and $s_b\in {\mathcal{N}}_S(v_i;P)$ is a candidate destination. Let $P^{i\to b}$ denote the trial mapping obtained by assigning only $v_i$ to $s_b$. The source and destination loads before and after the trial movement are evaluated using (6) and (7). The reduction in their local maximum load is

$$\begin{array}{cc}\hfill L_{i,b}^{\mathrm{old}}& =\max \{L_a\left(P\right),L_b\left(P\right)\},\hfill \\ \hfill L_{i,b}^{\mathrm{new}}& =\max \{L_a\left(P^{i\to b}\right),L_b\left(P^{i\to b}\right)\},\hfill \\ \hfill \Delta L_{i,b}& =L_{i,b}^{\mathrm{old}}-L_{i,b}^{\mathrm{new}}.\hfill \end{array}$$

(17)

When evaluating Equation (17), all weighted edges incident to $v_i$ are reclassified under the trial mapping. An edge that changes from intra-shard to cross-shard is incorporated into the updated ${\mathrm{Ex}}_k$, while an edge that changes from cross-shard to intra-shard is incorporated into the updated ${\mathrm{In}}_k$. Because a cross-shard edge contributes to the loads of both participating shards under (7), both newly created and removed cross-shard relationships affect $\Delta L_{i,b}$.

A positive $\Delta L_{i,b}$ indicates that the movement reduces the local maximum load of the source–destination shard pair. If several candidates produce a positive reduction, the candidate with the largest load improvement is selected:

$$s_i^{\ast }\in \underset{\begin{array}{c}{s}_b\in {\mathcal{N}}_S(v_i;P)\\ \Delta L_{i,b}>0\end{array}}{\arg \max }\Delta L_{i,b}.$$

(18)

Under the selection rule in Equation (18), if no candidate produces a positive gain, $v_i$ remains on its current shard. The acceptance rule is load-oriented and does not impose an additional requirement that every accepted movement monotonically reduce the global $\mathrm{CTR}\left(P\right)$. Instead, changes in cross-shard processing are incorporated into both the source- and destination-shard loads through ${\mathrm{Ex}}_k\left(P\right)$. This design is consistent with the staged operation of LB-Louvain: Louvain-based community extraction primarily preserves locality, whereas boundary refinement alleviates residual load concentration.

Each accepted movement replaces the current shard identifier of one account with another valid shard identifier. Therefore, Algorithm 2 preserves the unique-assignment constraint in (4). Candidate destinations are restricted to neighbor shards, keeping each refinement step tied to observed transaction relationships while limiting the adjustment scope. Together with the preceding community-level placement, these local movements provide fine-grained correction for residual load concentration.

Boundary refinement is implemented as an iterative local-improvement procedure. Account movements are evaluated according to their effect on the maximum load of the involved source–destination shard pair, while candidate destinations remain restricted to shards connected through observed transaction relationships. This design keeps the refinement focused on residual load concentration without discarding the locality structure established by the preceding community-level placement. Account-processing order and deterministic tie resolution determine the sequence of local improvements, yielding a tractable procedure for constructing the final feasible account mapping.

In the implementation used for the experiments, boundary refinement is organized into repeated passes. The procedure terminates when a complete refinement pass accepts no account movement, while a maximum of 70 passes is imposed as a finite implementation safeguard. This stopping rule combines an adaptive no-movement condition with a fixed upper bound on refinement effort.

Algorithms 1 and 2 construct the target account mapping only. They do not perform account-state transfer or change the active account locations during partition computation.

4.5. Complexity Analysis

The computational cost is decomposed according to the stages described above. Aggregating the historical transaction window requires $O\left(\left|T^H\right|\right)$ time and produces an account graph stored in $O\left(\right|V|+|E\left|\right)$ space. If standard Louvain [13] performs $r_1$ edge-processing passes across its levels, its implementation-oriented time complexity is $O\left(r_1\left|E\right|\right)$. Computing the weighted community statistics requires one additional scan of the graph, while ordering the R communities requires $O\left(R\log R\right)$ time.

During Algorithm 1, selecting the currently least-loaded shard requires scanning at most K shard loads for each community, resulting in $O\left(RK\right)$ time. The intra-shard and cross-shard statistics are updated incrementally as community placements become known.

Algorithm 2 Boundary-Account Rebalancing

Input: Weighted graph $G=(V,E,W)$; initial mapping $P^{\left(0\right)}$; physical-shard set S; current shard loads $\{L_1,\dots ,L_K\}$.

Output: Target mapping $P^{\mathrm{new}}$.

1: $P\leftarrow P^{\left(0\right)}$

2: Set $\mathit{needCheck}\left[v_i\right]\leftarrow \mathrm{true}$ for every $v_i\in V$

3: while there exists $v_i\in V$ with $\mathit{needCheck}\left[v_i\right]=\mathrm{true}$ do

4:     Select one such account $v_i$

5:     $\mathit{needCheck}\left[v_i\right]\leftarrow \mathrm{false}$

6:     $s_a\leftarrow P\left(v_i\right)$

7:     $S_{\mathrm{cand}}\leftarrow {\mathcal{N}}_S(v_i;P)$

8:     $s_i^{\ast }\leftarrow s_a$; $\mathit{bestGain}\leftarrow 0$

9:     for each $s_b\in S_{\mathrm{cand}}$ do

10:        Construct the trial mapping $P^{i\to b}$

11:        Reclassify the weighted edges incident to $v_i$

12:        Compute tentative source and destination loads using (6) and (7)

13:        Compute $\Delta L_{i,b}$ using (17)

14:        if $\Delta L_{i,b}>\mathit{bestGain}$ then

15:            $\mathit{bestGain}\leftarrow \Delta L_{i,b}$

16:            $s_i^{\ast }\leftarrow s_b$

17:        end if

18:     end for

19:     if $s_i^{\ast }\ne s_a$ then

20:        $P\left(v_i\right)\leftarrow s_i^{\ast }$

21:        Update the affected shard loads and account sets

22:        Set $\mathit{needCheck}\left[v_j\right]\leftarrow \mathrm{true}$ for every $v_j\in \mathcal{N}\left(v_i\right)$

23:     end if

24: end while

25: $P^{\mathrm{new}}\leftarrow P$

26: return $P^{\mathrm{new}}$

During Algorithm 2, candidate shards are obtained from the transaction neighbors of each boundary account, and the affected weighted edges are processed to evaluate the source and destination loads. If boundary refinement performs $r_2$ effective edge-processing passes, its implementation-oriented time complexity is estimated as $O\left(r_2|E|\right)$. Therefore, the overall time complexity is

$$O\left(\left|T^H\right|+r_1\left|E\right|+R\log R+RK+r_2\left|E\right|\right).$$

(19)

The additional storage consists of community labels and statistics, the account-to-shard mapping, shard-load records, and the boundary-account worklist. Excluding the input graph, these data require $O\left(\right|V|+R+K)$ space. The iteration counts $r_1$ and $r_2$ depend on the graph structure and the sequence of accepted movements. In the evaluated prototype, boundary refinement is additionally capped at 70 passes as described above; this implementation cap does not change the stage-wise complexity decomposition in (19). Therefore, (19) is an implementation-oriented estimate rather than a strict real-time bound or an asymptotic scalability claim.

5. Experimental Evaluation and Discussion

This section evaluates LB-Louvain in terms of partition quality, shard-level queue balance, and end-to-end execution under replayed Ethereum transfer workloads. A separate Transaction-Aware Activation experiment evaluates the application of the generated target mapping.

5.1. Experimental Setup and Reproducibility

The revised evaluation distinguishes the controlled revision experiments from the archived experiments reported in the original submission. The controlled experiments were conducted on BlockEmulator [25] under Windows 11 using Go 1.19.13. The host was equipped with an Intel Core i9-14900HX processor (24 physical cores and 32 logical processors) and 31.73 GB of memory. Unless otherwise stated, the controlled configuration used four physical shards with four PBFT [26] nodes per shard, a block interval of 5 s, a transaction-count block capacity of 2000 transactions, a PBFT timeout of 20,000 ms, a transaction batch size of 16,000, an injection rate of 1500 TXs/s, and a repartitioning interval of 50 s. The configured Bandwidth parameter was 10,000,000; we report the configuration value directly rather than reinterpret it as an independently measured network throughput.

The controlled experiments use the selectedTxs_300K.csv workload distributed with the open-source BlockEmulator project. The file contains 300,000 selected historical Ethereum transactions and is identified by SHA-256 checksum 12297773F5F3E04E4631315D56A86001C43BA3CA001C3C84EFCC923F06CA63BF. BlockEmulator describes this workload as being derived from historical Ethereum transactions available from XBlock-ETH [27]; however, the upstream project does not provide the original selection procedure, Ethereum block-number range, or date range for this prepackaged dataset. We therefore report the exact distributed workload and checksum rather than infer unavailable upstream provenance metadata. For the full 300,000-transaction controlled workload, the graph constructed according to Equation (3) contains 54,403 unique accounts and 64,378 undirected weighted account-pair edges, and standard Louvain yields 2,968 logical communities under the deterministic controlled configuration. Within the partitioning pipeline, repeated transfers between the same unordered account pair are aggregated into the edge weight $w_{ij}$ defined in Equation (3).

Each formal controlled configuration is executed five times as an independent system run under identical settings. We report the mean, sample standard deviation, and 95% confidence interval based on these five runs. The partitioning path uses the deterministic execution mode for a fixed input and configuration; therefore, these repetitions are repeated system executions rather than different algorithmic random seeds or independently sampled transaction traces. Variation across repetitions consequently reflects system-level execution variability under the same partitioning input and configuration. For the component ablation, M0 consists of standard Louvain followed by deterministic non-load-aware community placement with boundary refinement disabled; M1 adds the proposed load-aware community-to-shard assignment; and M2 denotes the complete LB-Louvain pipeline. Unless varied explicitly, the cross-shard load coefficient is set to $\beta =2.0$. The boundary-refinement stage terminates when a complete pass accepts no account movement or when the implementation cap of 70 iterations is reached. The standard Louvain community-extraction stage is used without changing its modularity objective or local-moving rule; the LB-Louvain-specific processing begins with the subsequent community-to-shard assignment and boundary-account refinement.

The archived experiments from the original submission were executed on a different testbed (Ubuntu 20.04, Intel Core i5-13600KF, and 32 GB memory) and span multiple workload sizes, arrival rates, and shard-count configurations. We therefore organize the evaluation into two complementary evidence sets: the new five-run controlled experiments provide repeated measurements under a unified revision configuration, while the archived experiments preserve broader coverage across arrival rates and shard counts.

The underlying BlockEmulator platform is publicly available [25]. The modified LB-Louvain implementation used for the present experiments is not publicly released; accordingly, the manuscript reports the evaluated workload checksum, controlled configuration, algorithm variants, and experimental repetition policy explicitly rather than implying public availability of the modified code.

Additional controlled numerical comparisons are limited to CLPA, for which a compatible runnable implementation is available in the evaluated BlockEmulator framework. Monoxide is retained in the archived evidence, while TxAllo, ShardCutter, and workload-constrained alternatives are compared at the mechanism level in Section 2 because compatible implementations were not available in the evaluated codebase.

Table 1. Controlled revision configuration and reviewer-driven experiment variations.

Parameter	Default Controlled Setting	Variation Where Applicable
Platform	BlockEmulator [25]	Fixed
Dataset	selectedTxs_300K.csv	Fixed base workload
Number of transactions	300,000	50,000–300,000 transaction prefixes in the scalability experiment
Transaction injection rate	1500 TXs/s	Fixed in the controlled reviewer experiments unless stated otherwise
Physical shards	4	4, 8, 12, 16, 20, and 24 in the scalability experiment
PBFT nodes per shard	4	Fixed
Repartitioning interval	50 s	25, 50, and 100 s in the adaptation/cadence experiments
Block interval	5 s	Fixed
Block capacity	2000 transactions	Fixed; byte-based block sizing disabled
PBFT timeout	20,000 ms	Fixed
Transaction batch size	16,000	Fixed
Cross-shard load coefficient $\beta$	2.0	1.0, 1.5, 2.0, 3.0, and 4.0 in the sensitivity experiment
Partitioning variant	M2 (complete LB-Louvain)	M0, M1, and M2 in the component ablation
Configured Bandwidth parameter	10,000,000	Fixed
Operating system	Windows 11	Fixed
Implementation	Go 1.19.13	Fixed
CPU	Intel Core i9-14900HX, 24 cores/32 logical processors	Fixed
Memory	31.73 GB	Fixed
Formal repetitions	5 independent identical-configuration system runs	Fixed for the reported reviewer experiments
Statistical summary	Mean, sample SD, and 95% confidence interval	No statistical-significance test is claimed

summarizes the default controlled configuration and the parameters varied in the reviewer-driven experiments.

5.2. Controlled Baseline and Component Ablation

To isolate the contributions of the two LB-Louvain refinement stages, we conduct a controlled component-wise ablation together with the native CLPA baseline. All configurations use the same 300,000-transaction replay workload, an injection rate of 1500 TXs/s, four physical shards with four PBFT nodes per shard, and a 50 s repartitioning interval. Each configuration is independently repeated five times under identical settings. M0 uses standard Louvain followed by deterministic non-load-aware community-to-shard placement, with boundary refinement disabled. M1 adds the proposed load-aware community-to-shard assignment to M0, while M2 denotes the complete LB-Louvain pipeline with both load-aware assignment and boundary-account refinement.

Figure 3 first compares the complete LB-Louvain pipeline with CLPA under the controlled configuration. At the level of the five-run means, M2 reduces the cross-shard transaction ratio from 0.3322 for CLPA to 0.3252, while increasing active throughput from 1039.4 to 1244.6 TXs/s. The corresponding average confirmation latency decreases from 41.08 to 37.23 s, and the peak shard-queue standard deviation decreases from 12,724.7 to 7693.9 transactions. These differences are interpreted descriptively under the evaluated workload; no statistical-significance claim is made.

The component-wise comparison further clarifies the roles of the two proposed refinement stages. Relative to M0, M1 increases active throughput by approximately 1.84% and reduces the peak shard-queue standard deviation by approximately 12.53%, while the cross-shard transaction ratio increases by approximately 0.73%. This pattern is consistent with Stage 2 prioritizing load-aware community placement at a small locality cost. Relative to M1, M2 reduces the cross-shard transaction ratio by approximately 0.92%, whereas the peak queue standard deviation changes by only approximately 0.46% and active throughput by approximately 0.42%. Thus, Stage 3 primarily recovers transaction locality while preserving the load-balance improvement obtained by Stage 2, confirming the complementary roles of coarse community placement and fine-grained boundary refinement.

5.3. Sensitivity to the Load Coefficient and Repartitioning Interval

We next examine whether the observed behavior of the complete LB-Louvain pipeline is sensitive to the cross-shard load coefficient $\beta$ and to the repartitioning interval. For the coefficient experiment, M2 is fixed and only $\beta$ is varied over $\{1.0,1.5,2.0,3.0,4.0\}$. For the interval experiment, M2 and $\beta =2.0$ are fixed while the configured repartitioning interval is varied among 25, 50, and 100 s. Each setting is repeated five times under the controlled configuration described in Section 5.1. The corresponding sensitivity results are shown in Figure 4.

Across $\beta \in [1,4]$, the mean cross-shard transaction ratio remains within a narrow range of 0.3199–0.3245, while the peak shard-queue standard deviation ranges from approximately 7532 to 7704 transactions. The evaluated values therefore show no sharp degradation over this coefficient range, supporting $\beta =2.0$ as a representative default operating point for the subsequent controlled experiments.

The repartitioning-interval experiment exposes a clearer tradeoff. Reducing the interval from 100 to 50 and 25 s decreases the mean confirmation latency from 51.30 to 37.58 and 24.49 s, respectively, but increases the fraction of the experiment span spent in reconfiguration from 6.08% to 11.45% and 21.51%. Because the same implementation parameter controls both interaction-history accumulation and repartitioning cadence, these results reflect their combined effect. When inter-reconfiguration gaps are included, the corresponding effective throughputs are approximately 1050.4, 1069.1, and 1050.2 TXs/s for the 100, 50, and 25 s settings, respectively. Accordingly, the 50 s interval provides a practical operating point that balances adaptation frequency with reconfiguration overhead under the evaluated configuration.

To characterize whether the interaction structure itself changes across the replay trace, we additionally divide the 300,000-transaction workload into contiguous non-overlapping segments and compare consecutive account and interaction sets. For 50,000-transaction segments, the mean account-set Jaccard similarity between consecutive segments is 0.4771 and the corresponding mean undirected-edge Jaccard similarity is 0.4521; on average, 7855 accounts in a segment were not present in the immediately preceding segment. Using 100,000-transaction segments gives mean account- and edge-set Jaccard similarities of 0.4301 and 0.4081, respectively, with an average of 11,757 newly observed accounts relative to the preceding segment. These diagnostics confirm substantial workload turnover in the replayed trace and motivate periodic reconstruction of the account-interaction graph rather than treating one historical partition as permanently representative.

We further construct a controlled abrupt-shift stress workload from two maximally dissimilar real contiguous 50,000-transaction segments of the same trace. The first segment is replayed for the first 150,000 logical transactions and the second for the remaining 150,000 transactions, creating a single workload-regime change while keeping M2 and $\beta =2.0$ fixed. Under this stress input, the 25, 50, and 100 s repartitioning settings yield whole-run mean cross-shard transaction ratios of 0.2153, 0.2658, and 0.3775 and mean confirmation latencies of 20.64, 31.54, and 50.22 s, respectively. The corresponding reconfiguration-time shares are 21.21%, 11.89%, and 5.59%. Thus, the same adaptation–overhead tradeoff remains visible under an abrupt regime change: more frequent rebuilding tracks the changed interaction structure more closely but consumes a larger fraction of execution time in reconfiguration. Because this workload is a controlled stress construction from two segments of the same historical trace rather than an independent trace, and because epoch boundaries do not provide a precise wall-clock recovery marker, we report whole-run behavior and do not claim a specific recovery time after the shift.

5.4. Controlled Partition-Runtime and Allocation Profile

To complement the theoretical complexity analysis with implementation-level measurements, we profile the complete LB-Louvain partitioning pipeline under the controlled revision environment. The profiling experiment fixes M2 and $\beta =2.0$ and varies the replayed-transaction prefix and the number of physical shards. Each configuration is executed five times under identical deterministic inputs. This experiment isolates the partitioning procedure itself and therefore does not include PBFT execution, state migration, network transfer, or end-to-end transaction processing.

With four physical shards fixed, increasing the replayed-transaction prefix from 50,000 to 300,000 increases the mean partition time from 17.32 to 55.26 ms. Over the same range, the measured total allocation delta increases from 14.12 to 36.93 MiB. At the largest evaluated prefix of 300,000 transactions, increasing the number of physical shards from 4 to 24 raises the mean partition time from 55.26 to 91.02 ms and the total allocation delta from 36.93 to 136.71 MiB.

Across all evaluated combinations of 50,000–300,000 replayed transactions and 4–24 physical shards, the observed partition time remains below 100 ms. This is substantially shorter than the default 50 s repartitioning interval used in the controlled system experiments, indicating that partition computation contributes only a small portion of the reconfiguration cycle under the evaluated settings. The profiling results therefore characterize the practical implementation cost of LB-Louvain across the tested workload and shard-count ranges, complementing the end-to-end reconfiguration measurements reported separately below. These measurements are summarized in Figure 5.

5.5. Archived End-to-End Throughput and Confirmation Latency

Figure 6 retains the end-to-end performance measurements reported in the original submission. These archived measurements were obtained on the earlier Ubuntu-based testbed described in Section 5.1 and are reported separately from the new five-run controlled revision experiments. They are retained to characterize the previously observed behavior across transaction arrival rates and shard counts, rather than to provide the statistical-confidence evidence used in the controlled comparisons above.

Under the fixed-eight-shard archived experiment in Figure 6a, increasing the transaction arrival rate to 2500 TXs/s yields confirmed throughputs of 1732 TPS for LB-Louvain, 1610 TPS for CLPA, and 876 TPS for Monoxide. The corresponding descriptive improvements of LB-Louvain are 7.6% relative to CLPA and 97.7% relative to Monoxide. At lower arrival rates, the performance differences are smaller, whereas the separation becomes larger under heavier offered load. This ordering is consistent with the combined effects of cross-shard relay processing and shard-level queue concentration, but the archived measurements do not isolate a numerical contribution from either effect.

The corresponding archived confirmation-latency measurements in Figure 6b show the same ordering. At 2500 TXs/s with eight shards, LB-Louvain records 49 s, compared with 54 s for CLPA and 152 s for Monoxide. Using the underlying unrounded measurement for the Monoxide comparison gives the previously reported 67.5% reduction, while the displayed values correspond to a 9.3% reduction relative to CLPA.

These latency and throughput observations are qualitatively consistent with lower relay demand and less concentrated transaction queues. However, the archived experiment and the controlled revision experiments were executed on different testbeds and are therefore not pooled, averaged, or compared statistically. In particular, the archived Figure 6 is not used to support the five-run confidence intervals reported in Figure 3 and Figure 4. Its role is to preserve the broader operating-point evidence from the original evaluation while the controlled revision experiments provide the reproducible statistical comparisons.

5.6. Archived Sensitivity to Shard Count and Arrival Rate

The remaining panels of Figure 6 retain the archived operating-point sweep across physical-shard counts and paired arrival-rate/shard-count settings. These measurements complement the controlled revision experiments, but they are interpreted descriptively because they were collected on the earlier testbed and do not constitute the new five-run scalability experiment.

In Figure 6c,d, the transaction arrival rate is fixed at 1500 TXs/s while the number of physical shards is varied. The archived LB-Louvain throughput increases from 932 TPS at four shards to 1234 TPS at 18 shards; at 18 shards, CLPA and Monoxide record 1175 and 1083 TPS, respectively. The increase is not linear, and these measurements neither identify 18 shards as an optimum nor imply linear system scaling. Relay processing, workload skew, block capacity, and the fixed emulator configuration jointly influence the observed end-to-end behavior.

Figure 6e,f further report archived measurements under paired arrival-rate and shard-count configurations. Under the $[1000,4]$ configuration, LB-Louvain records 999 TPS, corresponding to the previously reported descriptive improvements of 9.9% over CLPA and 92.3% over Monoxide. Under $[2500,24]$, the throughputs are 2014, 1786, and 1651 TPS for LB-Louvain, CLPA, and Monoxide, respectively. The corresponding archived latency measurements maintain the same overall ordering; under $[2500,24]$, the reported values are 9, 10, and 25 s, respectively.

The relative performance separation is therefore configuration-dependent rather than constant. These archived measurements show that the previously observed ordering is not confined to a single arrival rate or shard count, but they do not establish statistical confidence for the unreplicated operating points or predict behavior outside the evaluated configurations. Controlled partitioning-runtime and cumulative-allocation behavior are evaluated separately in the preceding controlled profiling experiment on the revision testbed.

5.7. Controlled Transaction-Aware Activation and Migration Overhead

We further evaluate how the target mapping produced by LB-Louvain is applied during state migration. This auxiliary experiment compares three activation modes under the controlled revision configuration: Fine-Grained activation (FG), Full Locking (FL), and Stop-the-World activation (STW). Each mode is independently executed five times with 300,000 replayed transactions, an injection rate of 1500 TXs/s, four physical shards, four PBFT nodes per shard, and a 50 s repartitioning interval. The partitioning method is fixed to the complete LB-Louvain pipeline with $\beta =2.0$.

Fine-Grained activation is an auxiliary implementation mechanism for applying the mapping produced by LB-Louvain rather than an additional account-partitioning stage. Before cutover, it establishes a migration fence for accounts whose shard assignments change. Transactions involving those accounts are deferred; late affected ordinary or relay transactions observed across cutover are deferred or rerouted against the updated mapping after state installation, while transactions unrelated to migrating accounts remain eligible for processing. The present evaluation characterizes this normal-execution path; fault injection involving Byzantine behavior, arbitrary process or leader failures, or interrupted state transfer remains future work.

Figure 7a shows the most direct effect of transaction-aware activation. Fine-Grained activation records a mean of 68,588 observed deferred transactions, compared with 113,888 under Full Locking, corresponding to a descriptive reduction of approximately 39.8%. The deferred-transaction metric for FG and FL comprises transactions deferred when the migration fence is established together with late affected transactions observed before local cutover. STW is not included in this comparison because its measured transaction-pool size at global-lock acquisition is an instantaneous queue snapshot rather than a cumulative count of deferred arrivals.

The reduction in the deferred set does not correspond to a material degradation in end-to-end execution. As shown in Figure 7b, the mean active throughputs are 1257.09, 1246.59, and 1244.78 TXs/s for FG, FL, and STW, respectively. Figure 7c reports corresponding mean confirmation latencies of 36.32, 36.17, and 37.30 s. Thus, FG provides comparable throughput and latency to FL while allowing a substantially smaller set of transactions to be deferred during migration. Relative to STW, FG records a slightly higher mean throughput and a lower mean confirmation latency under the evaluated workload. These differences are interpreted descriptively; no statistical-significance test is claimed.

Figure 7d further reports the measured mapping and state installation operation time. The five-run means are 229.97 ms for FG, 306.20 ms for FL, and 293.81 ms for STW. This measurement covers committed mapping update and state installation and terminates before the subsequent release and rerouting of deferred transactions; it therefore must not be interpreted as the complete migration duration. The comparatively wide confidence interval observed for FL reflects run-to-run variation in this operation under the evaluated configuration.

Table 2. Controlled migration and activation measurements.

Metric	FG	FL	STW
Observed deferred transactions	68,588	113,888	–
Active TPS (TX/s)	1257.09	1246.59	1244.78
Confirmation latency (s)	36.32	36.17	37.30
Migrated accounts	53,476	53,569	54,552
Initial state-transfer bytes (${10}^6$ B)	35.66	35.65	37.70
Mapping + state install time (ms)	229.97	306.20	293.81
Total reconfiguration time (ms)	8445.35	8615.91	7895.27

complements Figure 7 with additional migration-volume and reconfiguration measurements. The migrated-account counts are comparable across the three modes, indicating that the activation comparison applies essentially the same target-mapping workload. The initial state-transfer byte count is obtained from application/framing-level migration instrumentation and is therefore not interpreted as TCP/IP packet volume or independently measured WAN traffic. Moreover, the STW deferred-transaction entry is omitted because its recorded transaction-pool size at global-lock acquisition is an instantaneous queue snapshot rather than a cumulative count semantically equivalent to the FG/FL deferred-transaction metric.

The three activation modes emphasize different aspects of reconfiguration performance. STW records the lowest total reconfiguration time in this experiment, whereas FG substantially reduces the scope of transaction deferral while preserving processing continuity for unaffected transactions during mapping activation. With comparable end-to-end throughput and confirmation latency, the smaller deferred set highlights the principal benefit of Fine-Grained activation in the evaluated configuration. Across the three modes, the mean total reconfiguration times in Table 2 range from 7.90 to 8.62 s and remain below the configured 50 s repartitioning interval. Thus, under this controlled workload, the complete measured reconfiguration—rather than only the partition computation profiled in Section 5.4—fits within one repartitioning cycle.

5.8. Discussion

The controlled experiments provide a consistent interpretation of the two proposed refinement stages. The component-wise ablation in Figure 3 shows that the load-aware community-to-shard assignment primarily improves shard-level workload balance, while the subsequent boundary-account refinement recovers transaction locality with little change in the achieved queue balance. The complete M2 pipeline therefore reflects the intended coordination between locality and load rather than an improvement attributable to either refinement alone. The comparison with CLPA further shows that this coordination is accompanied by higher active throughput, lower confirmation latency, and substantially lower queue dispersion under the controlled configuration.

The sensitivity and profiling experiments clarify the operating range and practical cost of this behavior. Across $\beta \in [1,4]$, the evaluated partitioning results remain within a relatively narrow range, supporting $\beta =2.0$ as an evaluated default rather than a claimed optimum. Varying the repartitioning interval exposes an explicit adaptation–overhead tradeoff: shorter intervals reduce confirmation latency but increase the fraction of time spent in reconfiguration, whereas the 50 s setting provides a balanced evaluated operating point. The partition-only profiling results in Figure 5 further show that the measured partition computation remains below 100 ms for the tested 50,000–300,000 transaction prefixes and 4–24 shard configurations. These measurements characterize the evaluated implementation range and are not used to infer asymptotic or production-scale performance.

The archived end-to-end sweep in Figure 6 complements the controlled experiments by extending the evaluation across a broader range of arrival rates and shard counts. The auxiliary migration experiment in Figure 7 and Table 2 further shows that Fine-Grained activation can apply the generated mapping while substantially reducing transaction deferral and maintaining comparable end-to-end throughput and confirmation latency. Taken together, the controlled, archived, and migration experiments consistently support the coarse-to-fine design of LB-Louvain: community-level placement alleviates shard-load concentration, boundary refinement restores transaction locality, and Fine-Grained activation enables the resulting mapping to be applied while preserving transaction-processing continuity.

6. Conclusions

This paper presents LB-Louvain, a coarse-to-fine account-partitioning method for coordinating transaction locality and shard-load balance in account-based state sharding. By separating logical-community extraction from physical-shard placement, the method combines locality-preserving community structure with load-aware coarse assignment and restricted boundary refinement. The experimental evaluation demonstrates that these stages play complementary roles in reducing workload concentration while maintaining transaction locality, leading to consistent improvements in end-to-end system behavior across the evaluated configurations. The results further show that the resulting mapping can be adapted to changing interaction patterns and applied during state reconfiguration with limited disruption to transaction processing. Overall, LB-Louvain provides a practical framework for adaptive account placement under the evaluated relay-based transfer model. Future work will extend the evaluation to independent workloads, additional blockchain platforms, directed and smart-contract access patterns, geographically distributed deployments, and fault-injection studies of mapping activation.