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

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

I recommend major revision. The manuscript addresses an important challenge in account-based blockchain sharding and proposes a practical coarse-to-fine strategy that combines Louvain community detection, load-aware community assignment, and boundary-account refinement. The experimental results are promising; however, the novelty, optimization formulation, component-wise contribution, workload model, migration cost, statistical reliability, baseline coverage, scalability, and reproducibility require stronger validation before publication.

1. The novelty of LB-Louvain should be clarified more rigorously. Standard Louvain is used without modification, while the main additions are greedy load-aware community placement and restricted boundary-account movement. The authors should explain precisely which algorithmic components are novel and provide a more direct comparison with existing community-based and load-aware account-partitioning methods.

2. The paper formulates partition quality using two objectives—cross-shard transaction ratio and normalized load dispersion but LB-Louvain does not explicitly optimize this multi-objective formulation. In particular, boundary-account movements are accepted based on local load improvement and may increase the global cross-shard ratio. The authors should quantify this tradeoff and preferably provide Pareto-front or multi-objective analysis showing when load improvement is obtained at the expense of transaction locality.

3. The shard-load model is relatively simplified. Intra-shard transactions contribute one unit of processing work, while cross-shard transactions contribute one unit to each participating shard. In real systems, cross-shard transactions may incur substantially different consensus, relay, communication, storage, and verification costs. The authors should justify these coefficients experimentally or evaluate the method under different cross-shard cost models.

4. The transaction graph is converted into an undirected weighted graph, even though Ethereum transfers are directional and the adopted relay model assigns different roles to source and destination shards. Aggregating both directions may remove important workload information. A sensitivity experiment using a directed or role-aware graph representation would help establish whether this simplification affects partition quality.

5. The approach relies on historical transaction relationships, but the effect of workload drift is not sufficiently studied. Account-interaction patterns can change rapidly, making a partition computed from a previous 50-second window obsolete. The authors should evaluate abrupt workload shifts, newly active accounts, changing communities, and different historical-window lengths.

6. A major missing experiment is a proper component-wise ablation study. The manuscript evaluates LB-Louvain mainly as a complete pipeline, making it impossible to determine how much improvement comes from Louvain community extraction, load-aware community assignment, and boundary-account refinement individually. At minimum, the authors should compare standard Louvain, Louvain plus load-aware assignment, and the complete LB-Louvain method.

7. The complexity analysis is largely asymptotic and introduces graph-dependent iteration counts r1r_1 and r2r_2. Actual partitioning time and memory usage should be measured as the number of accounts, transactions, edges, communities, and shards increases. This is particularly important because repartitioning is performed periodically and must finish quickly enough to remain useful.

8. Account migration is treated separately from the main partitioning evaluation. However, the practical benefit of dynamic repartitioning depends directly on the number of migrated accounts, account-state sizes, network transfer cost, mapping-installation delay, and transactions blocked during migration. The authors should integrate partition computation and migration overhead into the end-to-end throughput and confirmation-latency evaluation.

9. The auxiliary Transaction-Aware Activation experiment is useful, but its relationship to LB-Louvain should be made clearer. Since this mechanism appears to constitute an additional contribution beyond account placement, the paper should specify whether it is part of LB-Louvain or merely an implementation mechanism. Its correctness under concurrent transactions, failures, delayed relay messages, and state-transfer interruptions should also be discussed.

10. The baseline set is too limited. Monoxide provides a relatively simple deterministic placement strategy, and CLPA is the main competitive graph-based baseline. The authors should include additional recent methods such as TxAllo, ShardCutter, workload-constrained graph partitioning, or other comparable adaptive account-placement methods wherever implementation compatibility allows.

11. The reported experimental results lack sufficient statistical validation. Many conclusions are based on individual curves or specific operating points, yet no standard deviations, confidence intervals, or significance tests are reported. The authors should repeat experiments with multiple transaction segments or seeds and provide statistical variability for throughput, latency, CTR, queue dispersion, and migration-related measurements.

12. The scalability evidence remains limited. Although up to 24 shards are simulated, all shards run within BlockEmulator on a single workstation, using one Ethereum transfer dataset. This does not fully represent geographically distributed blockchain nodes, heterogeneous network delays, failures, consensus variability, or much larger account graphs. Additional datasets and, ideally, experiments on a distributed physical or cloud testbed would strengthen the practical claims considerably.

Author Response

Dear Reviewer 1,

We sincerely thank you for your careful review and valuable and constructive comments. We have carefully considered all of your comments and revised the manuscript accordingly. All substantive revisions are highlighted in red in the revised manuscript to facilitate verification. Our point-by-point responses are provided below.

The page and line references in our responses refer to the revised 24-page manuscript. References within the reviewer comments are retained as received. Figure and table numbers refer to that manuscript; their relevant contents are provided below in text form.

Equations are written in linear text form for readability in this response. L_avg(P) denotes the average shard load; beta, Delta, and phi denote the corresponding Greek symbols; an underscore marks a subscript and ^ marks a superscript.

Comment 1:

The novelty of LB-Louvain should be clarified more rigorously. Standard Louvain is used without modification, while the main additions are greedy load-aware community placement and restricted boundary-account movement. The authors should explain precisely which algorithmic components are novel and provide a more direct comparison with existing community-based and load-aware account-partitioning methods.

Response 1: Thank you for this important comment. We agree that the contribution of LB-Louvain should be clearly distinguished from standard Louvain. In the revised manuscript, standard Louvain is explicitly used only for extracting graph-dependent logical communities, without modifying its modularity objective, local-moving rule, or community-aggregation procedure.

The LB-Louvain-specific design begins after community extraction. It consists of two subsequent stages: load-aware community-to-shard assignment, which maps the detected logical communities onto a fixed number of physical shards according to estimated shard loads, and restricted boundary-account refinement, which performs fine-grained correction only for boundary accounts and only toward shards containing their observed transaction neighbors.

We also strengthened the Related Work section to compare LB-Louvain more directly with CLPA, TxAllo, workload-constrained graph partitioning, and ShardCutter. The revised manuscript no longer presents the joint consideration of transaction locality and load balance as being novel by itself. Instead, the contribution is positioned around the coarse-to-fine placement mechanism for preserving graph-dependent community structure while distributing processing demand across a fixed physical-shard set.

In summary, we made the following revisions to clarify the contribution of LB-Louvain and its relationship with closely related account-partitioning methods.

Change 1. We revised the Related Work section to clarify the relationship between LB-Louvain and existing graph-based and load-aware account-partitioning methods, and to identify the specific fixed-shard placement problem addressed in this work. Relevant revised manuscript text (linear notation) is as follows:

"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."

Change 2. We further revised the method description to state explicitly that standard Louvain itself is unchanged and that a separate physical-shard placement stage is required after logical-community extraction. Relevant revised manuscript text (linear notation) is as follows:

"LB-Louvain adopts this standard modularity objective without changing the internal local-moving or community-aggregation rules of Louvain.

The resulting logical-community set is

C = {C_1, C_2,..., C_R},

where 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."

Location in the revised manuscript: Section 2, pp. 3-4, lines 113-139; Section 4.2, p. 8, lines 274-291; Sections 4.3-4.4, pp. 8-12; Section 5.2, pp. 14-15, lines 487-512, and Figure 3 (p. 15).

Comment 2:

The paper formulates partition quality using two objectives - cross-shard transaction ratio and normalized load dispersion - but LB-Louvain does not explicitly optimize this multi-objective formulation. In particular, boundary-account movements are accepted based on local load improvement and may increase the global cross-shard ratio. The authors should quantify this tradeoff and preferably provide Pareto-front or multi-objective analysis showing when load improvement is obtained at the expense of transaction locality.

Response 2: Thank you for this important comment. We agree that simply writing transaction locality and normalized shard-load dispersion as the two components of J(P) does not by itself define a rule for selecting a compromise mapping. We therefore clarified the role of Equation (9) and, more importantly, expanded the design rationale in Section 4.1 to explain how LB-Louvain coordinates the two criteria operationally.

Specifically, Equation (9) is used to evaluate feasible mappings along two dimensions: historical transaction locality and normalized shard-load dispersion. LB-Louvain does not combine these dimensions through a fixed weighted sum. Instead, it adopts a staged coarse-to-fine procedure. Standard Louvain first preserves dense historical transaction relationships at the community level. Stage 2 then assigns intact communities according to estimated shard load, and Stage 3 performs restricted account-level correction only for boundary accounts. In Stage 3, a movement is accepted only when it reduces the maximum estimated load of the corresponding source-destination shard pair. Candidate destinations are further restricted to shards containing observed transaction neighbors. Thus, the compromise is determined by an explicit staged decision rule rather than by optimizing an unspecified scalar combination of the two metrics.

We also quantified the observed trade-off through the component-wise ablation in Figure 3. From M0 to M1, the peak shard-queue standard deviation decreases by approximately 12.53%, while the cross-shard transaction ratio increases by approximately 0.73%. From M1 to M2, the cross-shard transaction ratio decreases by approximately 0.92%, while the peak queue standard deviation changes by only approximately 0.46%. These results show that the load-aware community-assignment stage primarily improves load balance at a small observed locality cost, whereas the boundary-refinement stage mainly recovers transaction locality while largely preserving the achieved load balance.

Since the implemented method neither introduces a scalar trade-off coefficient between the two components of J(P) nor enumerates alternative nondominated mappings, presenting a Pareto front would not faithfully represent the implemented decision procedure. We therefore report the two criteria separately and quantify their component-wise changes rather than claiming a Pareto-optimal or globally optimal mapping.

In summary, we made the following revisions to clarify the role of the two evaluation criteria, the operational rule used to coordinate them, and the resulting empirical trade-off.

Change 1. We clarified the role of Equation (9) and expanded the design rationale in Sections 3.3 and 4.1. Relevant revised manuscript text (linear notation) is as follows:

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

J(P) = (CTR(P), D(P)/L_avg(P)), P in F; F = {P: V -> S | P satisfies (4)}. (9)

where smaller values of the first and second components indicate better historical transaction locality and a more balanced shard-load distribution, respectively.

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(P) 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."

Change 2. We clarified the boundary-account movement rule to specify exactly when a local load improvement is accepted and how cross-shard effects are incorporated. Relevant revised manuscript text (linear notation) is as follows:

This restriction 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.

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. 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 CTR(P). Instead, changes in cross-shard processing are incorporated into both the source- and destination-shard loads through Ex_k(P). 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.

Change 3. We further quantified the resulting locality-load trade-off through the component-wise ablation in Section 5.2. Figure 3 and its key results are described in text in our response to Comment 6, where the component-wise ablation study is discussed in detail. The relevant result is summarized here:

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.

Location in the revised manuscript: Sections 3.3 and 4.1, p. 7, lines 233-261, Equation (9); Section 4.4, pp. 10-11, lines 349-376, Equations (16)-(18); Section 5.2, pp. 14-15, lines 503-512, and Figure 3 (p. 15).

Comment 3:

The shard-load model is relatively simplified. Intra-shard transactions contribute one unit of processing work, while cross-shard transactions contribute one unit to each participating shard. In real systems, cross-shard transactions may incur substantially different consensus, relay, communication, storage, and verification costs. The authors should justify these coefficients experimentally or evaluate the method under different cross-shard cost models.

Response 3: Thank you for pointing out this important issue. We agree that fixing the contribution of a cross-shard transaction to one unit at each participating shard is too restrictive to represent different relative cross-shard processing costs. In the original manuscript, the load model effectively used the same unit coefficient for intra-shard processing and for the contribution of a cross-shard transaction at each participating shard.

To address this concern, we generalized the shard-load estimate by introducing a cross-shard load coefficient beta > 0, so that the estimated load of shard s_k is defined as L_k(P) = In_k(P) + beta * Ex_k(P). The coefficient beta represents the relative contribution of cross-shard processing to the shard-load estimate. It is intentionally defined as an implementation-level relative processing-cost parameter rather than as a direct measurement of network latency, bandwidth consumption, hardware cost, or any individual consensus, relay, storage, or verification cost.

We further evaluated the complete LB-Louvain pipeline under beta in {1.0, 1.5, 2.0, 3.0, 4.0}, with five independent identical-configuration system runs for each setting. Across this range, the mean cross-shard transaction ratio remains between 0.3199 and 0.3245, while the peak shard-queue standard deviation remains approximately between 7532 and 7704 transactions. No sharp degradation is observed over the evaluated range. We therefore retain beta = 2.0 as the default value used in the subsequent controlled experiments, while not treating it as a universal or theoretically optimal coefficient.

In summary, we made the following revisions to generalize the shard-load model and evaluate its sensitivity to different relative cross-shard processing costs.

Change 1. We generalized the shard-load model in Section 3.3 by introducing the cross-shard load coefficient beta. Relevant revised manuscript text (linear notation) is as follows:

The estimated load of shard s_k and the average shard load are then defined as

L_k(P) = In_k(P) + beta * Ex_k(P); L_avg(P) = (1/K) * sum_(k=1 to K) L_k(P). (7)

where 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 Ex_k(P). 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}.

Change 2. We added a sensitivity experiment in Section 5.3 to evaluate LB-Louvain under different values of the cross-shard load coefficient. Relevant revised manuscript text (linear notation) is as follows:

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.

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.

Text description of Figure 4(a)-(b): beta is varied over 1.0, 1.5, 2.0, 3.0, and 4.0 with M2 fixed. The plotted outcomes are overall cross-shard transaction ratio and peak population standard deviation of shard queues. The reported mean ratio ranges from 0.3199 to 0.3245, and mean peak queue dispersion ranges from approximately 7532 to 7704 transactions. Error bars are 95% confidence intervals over five repeated system runs.

Figure 4(a)-(b). Sensitivity of the complete LB-Louvain pipeline to the cross-shard load coefficient beta: (a) overall cross-shard transaction ratio under different values of beta; and (b) peak population standard deviation of shard transaction-pool queues under different values of beta. Error bars denote 95% confidence intervals over five repeated system runs.

Location in the revised manuscript: Section 3.3, p. 6, Equation (7) and its coefficient explanation; Section 5.3, pp. 15-16, lines 514-525; Figure 4(a)-(b), p. 16.

Comment 4:

The transaction graph is converted into an undirected weighted graph, even though Ethereum transfers are directional and the adopted relay model assigns different roles to source and destination shards. Aggregating both directions may remove important workload information. A sensitivity experiment using a directed or role-aware graph representation would help establish whether this simplification affects partition quality.

Response 4: Thank you for raising this important issue. We agree that Ethereum transfers retain explicit sender and recipient roles during execution and that the source and destination shards perform different operations in the relay-based cross-shard path. We therefore revised the manuscript to distinguish these execution semantics from the graph representation used for account partitioning.

In the current partitioning model, the weight of an account pair represents its historical interaction frequency. Transfers in both directions between the same pair are aggregated because the locality criterion asks whether two frequently interacting accounts should be colocated: if they are assigned to the same shard, relay processing is avoided regardless of which endpoint acts as the sender in an individual transfer. This aggregation therefore does not mean that sender and recipient roles are treated as interchangeable during transaction execution.

To further characterize the extent of this aggregation, we examined the 300,000-transaction controlled workload. The trace contains 64,835 observed ordered account pairs, which collapse to 64,378 unordered account pairs; 457 unordered pairs contain transfers in both directions. This diagnostic confirms that directional interactions exist in the workload while also making explicit what information is collapsed by the current undirected representation.

We did not implement a complete directed or role-aware version of LB-Louvain in this revision. A valid directed sensitivity experiment would require more than replacing each undirected edge with directed arcs: the community-detection objective, shard-load accounting, and placement/refinement costs would also need to be reformulated consistently. Otherwise, the resulting comparison would mix incompatible objective definitions and would not isolate the effect of directionality reliably. We therefore clarified this modeling choice and its scope in the revised manuscript and identify a directed or role-aware extension as future work.

In summary, we made the following revisions to clarify the use of the undirected transaction graph, distinguish partitioning representation from execution semantics, and state the scope of the current model.

Change 1. We revised Section 3.2 to explain why transaction directions are aggregated for partitioning and to clarify that sender and recipient roles remain distinct during transaction execution. Relevant revised manuscript text (linear notation) is as follows:

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 in (5), 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.

Change 2. We also included directed access patterns among the extensions considered for future evaluation. Relevant revised manuscript text (linear notation) is as follows:

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.

Location in the revised manuscript: Section 3.2, pp. 5-6, including the discussion of undirected aggregation and distinct execution roles; Section 6, p. 22, lines 737-739. The ordered-pair counts above are a diagnostic reported in this response, not a claim that a directed implementation was added.

Comment 5:

The approach relies on historical transaction relationships, but the effect of workload drift is not sufficiently studied. Account-interaction patterns can change rapidly, making a partition computed from a previous 50-second window obsolete. The authors should evaluate abrupt workload shifts, newly active accounts, changing communities, and different historical-window lengths.

Response 5: Thank you for this important comment. We agree that a partition constructed from historical interactions must be evaluated under changing workload structure rather than assuming that one historical mapping remains representative indefinitely. We therefore expanded both the workload model and the controlled evaluation to characterize how LB-Louvain operates when observed accounts and interaction relationships change over time.

First, the revised manuscript explicitly treats the transaction graph as a retrospective signal constructed from the current historical window. Accounts that first appear in a later window enter the reconstructed graph from the first window in which they are observed. Thus, newly active accounts are incorporated when the interaction graph is rebuilt rather than being inferred from unavailable future activity. Because the graph is reconstructed from the current window before partitioning, changes in its account and interaction structure are subsequently reflected in the community extraction and account-placement procedure.

Second, we evaluated repartitioning intervals of 25, 50, and 100 s, with five repeated system runs for each setting. In the current implementation, the same parameter determines both the interaction-history accumulation interval and the repartitioning cadence. We therefore report this experiment as a joint history-window/reconfiguration-cadence sensitivity rather than treating it as an isolated history-window experiment. The mean confirmation latencies are 24.49, 37.58, and 51.30 s for the 25-, 50-, and 100-s settings, respectively, while the corresponding reconfiguration-time shares are 21.51%, 11.45%, and 6.08%. This exposes the expected adaptation-overhead trade-off: more frequent rebuilding adapts to recent interactions more quickly but spends a larger fraction of execution time in reconfiguration.

Third, we quantified workload turnover directly using contiguous non-overlapping segments of the 300,000-transaction trace. For 50,000-transaction segments, the mean account-set and undirected-edge Jaccard similarities between consecutive segments are 0.4771 and 0.4521, respectively, with an average of 7,855 accounts in a segment not present in the immediately preceding segment. For 100,000-transaction segments, the corresponding similarities are 0.4301 and 0.4081, with an average of 11,757 newly observed accounts relative to the preceding segment. These measurements show substantial turnover in both the active-account set and interaction structure, which in turn changes the graph on which Louvain community extraction is performed.

Finally, we constructed an 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, producing a single controlled workload-regime change. Under 25-, 50-, and 100-s repartitioning settings, the whole-run mean cross-shard transaction ratios are 0.2153, 0.2658, and 0.3775, respectively, while the corresponding mean confirmation latencies are 20.64, 31.54, and 50.22 s. The reconfiguration-time shares are 21.21%, 11.89%, and 5.59%. The results show the same adaptation-overhead behavior under an abrupt workload change: shorter rebuilding intervals track the changed interaction structure more closely, at the cost of greater reconfiguration overhead.

In summary, we made the following revisions to clarify the treatment of newly active accounts and to evaluate workload turnover, history-window/repartitioning sensitivity, and abrupt workload changes.

Change 1. We revised Section 3.2 to clarify that the account-interaction graph represents the transactions observed in the current historical window and to specify how newly active accounts enter subsequent reconstructed graphs. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We added a controlled sensitivity experiment in Section 5.3 to evaluate different history-window/repartitioning settings. Relevant revised manuscript text (linear notation) is as follows:

The repartitioning-interval experiment exposes a clearer trade-off. 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.

Text description of Figure 4(c)-(d): for repartitioning intervals of 25, 50, and 100 s, the mean confirmation latencies are 24.49, 37.58, and 51.30 s, and the reconfiguration-time shares are 21.51%, 11.45%, and 6.08%, respectively. Error bars are 95% confidence intervals over five repeated system runs. The interval also controls history accumulation, so this is a joint history-window/reconfiguration-cadence experiment.

Figure 4(c)-(d). Sensitivity of the complete LB-Louvain pipeline to the repartitioning interval: (c) average transaction confirmation latency under repartitioning intervals of 25, 50, and 100 s; and (d) the corresponding fraction of the experiment span spent in reconfiguration. In the current prototype, the repartitioning interval also determines the interaction-history accumulation interval; therefore, panels (c) and (d) characterize the joint history-window/reconfiguration-cadence trade-off rather than an isolated history-window effect. Error bars denote 95% confidence intervals over five repeated system runs.

Change 3. We further added workload-turnover diagnostics based on consecutive real transaction segments to characterize changes in active accounts and interaction structure. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 4. We added an abrupt-shift stress workload to examine the behavior of the method under a controlled change in interaction regime. Relevant revised manuscript text (linear notation) is as follows:

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 trade-off 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.

Location in the revised manuscript: Section 3.2, p. 5, lines 178-184; Section 5.3, pp. 15-17, lines 514-559; Figure 4(c)-(d), p. 16.

Comment 6:

A major missing experiment is a proper component-wise ablation study. The manuscript evaluates LB-Louvain mainly as a complete pipeline, making it impossible to determine how much improvement comes from Louvain community extraction, load-aware community assignment, and boundary-account refinement individually. At minimum, the authors should compare standard Louvain, Louvain plus load-aware assignment, and the complete LB-Louvain method.

Response 6: Thank you for this important suggestion. We agree that evaluating only the complete LB-Louvain pipeline does not establish the individual contributions of the load-aware community-assignment and boundary-refinement stages. We therefore added a controlled component-wise ablation with three variants, M0, M1, and M2, under identical workload and system configurations, with five independent repeated system runs for each variant.

M0 uses standard Louvain for logical-community extraction, followed by deterministic non-load-aware community-to-shard placement, with boundary-account refinement disabled. A baseline community-to-shard placement step is necessary because standard Louvain produces a graph-dependent number of logical communities that generally differs from the configured number of physical shards; therefore, Louvain community labels cannot themselves be used directly as physical-shard identifiers. M0 consequently serves as the standard-Louvain-based physical-placement baseline without either of the two proposed LB-Louvain refinement stages. M1 adds the proposed load-aware community-to-shard assignment to M0 while keeping boundary refinement disabled. M2 is the complete LB-Louvain pipeline and adds the proposed boundary-account refinement to M1.

The ablation results separate the roles of the two proposed 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%. Thus, Stage 2 primarily improves shard-load balance, with a small observed locality cost. Relative to M1, M2 reduces the cross-shard transaction ratio by approximately 0.92%, while the peak queue standard deviation and active throughput change by only approximately 0.46% and 0.42%, respectively. Thus, Stage 3 primarily recovers transaction locality while largely preserving the load-balance improvement achieved by Stage 2. These results directly distinguish the empirical contributions of the two LB-Louvain-specific stages rather than attributing the observed behavior to the complete pipeline as an indivisible unit.

In summary, we added a controlled component-wise ablation to isolate the effects of standard Louvain-based community extraction, load-aware community-to-shard assignment, and boundary-account refinement.

Change 1. We added the formal definitions of the three ablation variants in Section 5.2. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We added Figure 3 to report the controlled component-wise comparison in terms of transaction locality, active throughput, confirmation latency, and shard-queue dispersion.

Text description of Figure 3: panels (a)-(d) compare CLPA, M0, M1, and M2 using overall cross-shard transaction ratio, active throughput excluding inter-reconfiguration gaps, average confirmation latency, and peak population standard deviation of shard queues. Each point is a five-run mean and the error bars are 95% confidence intervals.

The numerical comparison reported in Section 5.2 is: CLPA versus M2 cross-shard transaction ratio = 0.3322 versus 0.3252; active throughput = 1039.4 versus 1244.6 TXs/s; average confirmation latency = 41.08 versus 37.23 s; peak shard-queue standard deviation = 12,724.7 versus 7693.9 transactions. The component-wise percentage changes are reported in Section 5.2 of the revised manuscript. The comparisons are descriptive.

Figure 3. Controlled baseline comparison and component-wise ablation under 300,000 replayed transactions, an injection rate of 1500 TXs/s, four physical shards with four PBFT nodes per shard, and a 50-s repartitioning interval: (a) overall cross-shard transaction ratio; (b) active throughput excluding inter-reconfiguration gaps; (c) average transaction confirmation latency; and (d) peak population standard deviation of shard transaction-pool queues. M0 uses standard Louvain with deterministic non-load-aware community placement and no boundary refinement; M1 adds the proposed load-aware community-to-shard assignment; and M2 denotes the complete LB-Louvain pipeline. Error bars denote 95% confidence intervals over five repeated system runs.

Change 3. We added a component-wise analysis to quantify the contribution of each proposed refinement stage. Relevant revised manuscript text (linear notation) is as follows:

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.

Location in the revised manuscript: Section 5.1, p. 13, lines 452-467; Section 5.2, pp. 14-15, lines 487-512; Figure 3, p. 15.

Comment 7:

The complexity analysis is largely asymptotic and introduces graph-dependent iteration counts r_1 and r_2. Actual partitioning time and memory usage should be measured as the number of accounts, transactions, edges, communities, and shards increases. This is particularly important because repartitioning is performed periodically and must finish quickly enough to remain useful.

Response 7: Thank you for this important comment. We agree that the stage-wise complexity expression alone is insufficient to establish the practical cost of periodic repartitioning. We therefore revised the complexity discussion to clarify the meaning and scope of the graph-dependent iteration counts and added controlled implementation-level profiling of the complete LB-Louvain partitioning path.

In the revised complexity analysis, r_1 denotes the graph-dependent number of edge-processing passes performed by standard Louvain across its levels, while r_2 denotes the number of boundary-refinement passes. Both depend on the graph structure and, for refinement, on the sequence of accepted movements. In the evaluated implementation, boundary refinement terminates after a complete pass with no accepted account movement or when the finite implementation cap of 70 passes is reached. We therefore retain Equation (19) only as a stage-wise implementation-oriented cost decomposition and do not interpret it as a strict real-time upper bound or an asymptotic scalability guarantee.

To provide direct empirical evidence, we added a five-run partition-only profiling experiment that varies the replayed-transaction prefix from 50,000 to 300,000 transactions and the number of physical shards from 4 to 24. With four physical shards fixed, increasing the replayed-transaction prefix from 50,000 to 300,000 increases mean partition time from 17.32 to 55.26 ms and the measured cumulative allocation delta from 14.12 to 36.93 MiB. At the 300,000-transaction prefix, increasing the physical-shard count from 4 to 24 increases mean partition time from 55.26 to 91.02 ms and cumulative allocation delta from 36.93 to 136.71 MiB. Across all evaluated combinations, partition time remains below 100 ms.

We also clarify the scope of the reported memory metric. The profiling instrumentation reports the cumulative allocation delta incurred during the partitioning procedure; it is not a measurement of peak resident memory. The profiling experiment isolates partition computation and therefore excludes PBFT execution, network transfer, state migration, and end-to-end transaction processing. These additional reconfiguration costs are evaluated separately in the migration/activation experiment. The full 300,000-transaction controlled workload contains 54,403 unique accounts, 64,378 undirected weighted account-pair edges, and 2,968 Louvain communities, so the largest profiled point corresponds to the complete controlled graph rather than to an abstract synthetic graph size.

In summary, we revised the complexity discussion and added controlled partition-time and allocation profiling to provide implementation-level evidence over increasing workload sizes and shard counts.

Change 1. We clarified the termination condition in Section 4.4 and the interpretation of the graph-dependent iteration counts in Section 4.5. Relevant revised manuscript text is as follows:

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. 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(|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.

Change 2. We added a controlled partition-runtime and allocation-profile experiment in Section 5.4. Relevant revised manuscript text (linear notation) is as follows:

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.

Text description of Figure 5: panels (a) and (c) vary the transaction prefix from 50,000 to 300,000 with four shards; mean partition time increases from 17.32 to 55.26 ms and cumulative allocation delta from 14.12 to 36.93 MiB. Panels (b) and (d) vary shard count with 300,000 transactions; from 4 to 24 shards, mean partition time increases from 55.26 to 91.02 ms and cumulative allocation delta from 36.93 to 136.71 MiB. Error bars are 95% confidence intervals over five profiling runs. The allocation metric is cumulative allocation during partitioning, not peak resident memory.

Figure 5. Controlled partitioning-cost profile of the complete LB-Louvain pipeline: (a) partition time versus replayed-transaction prefix with four physical shards; (b) partition time versus physical-shard count with 300,000 replayed transactions; (c) total allocation delta versus replayed-transaction prefix with four physical shards; and (d) total allocation delta versus physical-shard count with 300,000 replayed transactions. The allocation metric is the measured cumulative allocation delta during the partitioning procedure rather than peak resident memory. Error bars denote 95% confidence intervals over five repeated profiling runs under identical configurations.

Location in the revised manuscript: Section 4.4, p. 12, lines 391-395; Section 4.5, p. 12, lines 399-421, Equation (19); Section 5.4, p. 17, lines 561-581; Figure 5, p. 18.

Comment 8:

Account migration is treated separately from the main partitioning evaluation. However, the practical benefit of dynamic repartitioning depends directly on the number of migrated accounts, account-state sizes, network transfer cost, mapping-installation delay, and transactions blocked during migration. The authors should integrate partition computation and migration overhead into the end-to-end throughput and confirmation-latency evaluation.

Response 8: Thank you for this important comment. We agree that evaluating the target partition alone is insufficient to characterize the practical effect of dynamic repartitioning. We therefore added a controlled migration and mapping-activation experiment in which the partitioning method is fixed to the complete LB-Louvain pipeline and the generated target mapping is applied during system execution. Fine-Grained activation (FG), Full Locking (FL), and Stop-the-World activation (STW) are each independently evaluated over five repeated system runs under the same 300,000-transaction workload, 1500 TXs/s injection rate, four physical shards, four PBFT nodes per shard, and 50-s repartitioning interval.

The new evaluation directly connects migration behavior with end-to-end transaction execution. FG records a mean of 68,588 observed deferred transactions, compared with 113,888 under FL, corresponding to a descriptive reduction of approximately 39.8%. The mean active throughputs are 1257.09, 1246.59, and 1244.78 TXs/s for FG, FL, and STW, respectively, while the corresponding mean confirmation latencies are 36.32, 36.17, and 37.30 s. Thus, the narrower deferred set under FG is achieved without a material degradation of the measured throughput or confirmation latency relative to the other activation modes. These differences are interpreted descriptively, and no statistical-significance claim is made.

We also added explicit migration-volume and reconfiguration measurements. The mean migrated-account counts are 53,476, 53,569, and 54,552 for FG, FL, and STW, respectively. The corresponding initial state-transfer volumes are 35.66 * 10^6, 35.65 * 10^6, and 37.70 * 10^6 B. The mean mapping-and-state-installation times are 229.97, 306.20, and 293.81 ms, while the mean total reconfiguration times are 8445.35, 8615.91, and 7895.27 ms. Importantly, the state-transfer byte metric is obtained from application/framing-level migration instrumentation and is not interpreted as TCP/IP packet volume or independently measured WAN traffic.

The results also clarify the trade-off among the activation modes. STW has the lowest mean total reconfiguration time in this experiment, whereas FG's principal observed benefit is a substantially smaller scope of transaction deferral while allowing transactions unrelated to migrating accounts to continue processing. Across all three modes, the mean total reconfiguration time remains between approximately 7.90 and 8.62 s, well below the configured 50-s repartitioning interval. Therefore, under the evaluated workload, the complete measured reconfiguration - not only the partition computation profiled separately in Section 5.4 - fits within one repartitioning cycle.

In summary, we added a controlled migration and mapping-activation evaluation that reports migration volume, deferred transactions, mapping/state-installation time, total reconfiguration time, and the corresponding end-to-end throughput and confirmation latency.

Change 1. We added Section 5.7 to evaluate how the target mapping generated by LB-Louvain is applied during state migration. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We added Figure 7 to connect migration-related transaction deferral and mapping/state installation with end-to-end throughput and confirmation latency.

Text description of Figure 7: panel (a) reports mean observed deferred transactions of 68,588 for FG and 113,888 for FL; STW is omitted because its instantaneous queue snapshot is not directly comparable. Panels (b)-(d), in FG/FL/STW order, report active throughput of 1257.09/1246.59/1244.78 TXs/s, confirmation latency of 36.32/36.17/37.30 s, and mapping/state installation time of 229.97/306.20/293.81 ms. Installation timing ends before deferred-transaction release and rerouting. Error bars are 95% confidence intervals over five repeated system runs.

Figure 7. Controlled comparison of Transaction-Aware Activation and migration overhead: (a) observed migration-deferred transactions for Fine-Grained activation (FG) and Full Locking (FL); (b) active throughput for FG, FL, and Stop-the-World activation (STW); (c) average transaction confirmation latency; and (d) mapping and state installation time. The STW transaction-pool snapshot at global-lock acquisition is not directly comparable with the cumulative deferred-transaction count used for FG and FL and is therefore omitted from panel (a). Mapping and state installation timing ends before deferred-transaction release and rerouting. Error bars denote 95% confidence intervals over five repeated system runs.

Change 3. We added the following analysis to relate the reduced transaction-deferral scope to end-to-end throughput and confirmation latency:

Figure 7(a) 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 7(b), the mean active throughputs are 1257.09, 1246.59, and 1244.78 TXs/s for FG, FL, and STW, respectively. Figure 7(c) 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.

Change 4. We separately report the mapping and state installation operation time and clarify that it is not equivalent to the complete migration duration. Relevant revised manuscript text (linear notation) is as follows:

Figure 7(d) 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.

Change 5. We added Table 2 to report migrated accounts, state-transfer volume, mapping/state-installation time, and complete reconfiguration time together with the end-to-end transaction metrics.

Table 2. Controlled migration and activation measurements.

Table 2 values in text form. Each value is a five-run mean. FG denotes Fine-Grained activation; FL denotes Full Locking; STW denotes Stop-the-World activation.

Observed deferred transactions: FG = 68,588; FL = 113,888; STW = not reported on this basis, because its instantaneous queue snapshot is not comparable with the cumulative FG/FL metric.

Active throughput (TX/s): FG = 1257.09; FL = 1246.59; STW = 1244.78.

Confirmation latency (s): FG = 36.32; FL = 36.17; STW = 37.30.

Migrated accounts: FG = 53,476; FL = 53,569; STW = 54,552.

Initial state-transfer bytes (10^6 B): FG = 35.66; FL = 35.65; STW = 37.70.

Mapping and state installation time (ms): FG = 229.97; FL = 306.20; STW = 293.81.

Total reconfiguration time (ms): FG = 8445.35; FL = 8615.91; STW = 7895.27.

Change 6. We further clarified the interpretation of the migration-volume and complete-reconfiguration measurements. Relevant revised manuscript text (linear notation) is as follows:

Table 2 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.

Location in the revised manuscript: Section 5.7, pp. 20-21, lines 637-694; Figure 7, p. 20; Table 2, p. 21.

Comment 9:

The auxiliary Transaction-Aware Activation experiment is useful, but its relationship to LB-Louvain should be made clearer. Since this mechanism appears to constitute an additional contribution beyond account placement, the paper should specify whether it is part of LB-Louvain or merely an implementation mechanism. Its correctness under concurrent transactions, failures, delayed relay messages, and state-transfer interruptions should also be discussed.

Response 9: Thank you for this important comment. We have revised the manuscript to distinguish account-partitioning decisions from mapping activation more explicitly. LB-Louvain itself constructs the target account-to-shard mapping through standard Louvain community extraction, load-aware community-to-shard assignment, and boundary-account refinement. Transaction-Aware Activation is an auxiliary implementation mechanism that is invoked after this target mapping has been determined; it applies the mapping by coordinating account-state relocation and transaction handling during cutover. It is therefore not an additional account-partitioning stage of the LB-Louvain heuristic. The partitioning algorithms themselves do not transfer account state or change active account locations while computing the target mapping.

For the concurrent normal-execution path evaluated in this work, Fine-Grained activation establishes a migration fence for accounts whose shard assignments change. Transactions involving migrating accounts are deferred, while transactions unrelated to those accounts remain eligible for processing. Late affected ordinary or relay transactions observed across cutover are deferred or rerouted according to the updated mapping after state installation. Thus, the evaluated mechanism explicitly covers concurrent transaction arrival and late affected transactions across the mapping cutover rather than assuming that transaction processing stops globally.

We have also narrowed the correctness scope explicitly. The present experiments and regression checks characterize this normal-execution fence/defer/reroute path, but they do not constitute a proof of correctness under arbitrary failures. Fault injection involving Byzantine behavior, arbitrary process or leader failures, or interrupted state transfer was not evaluated. We therefore do not claim Byzantine-safe migration, exactly-once behavior under arbitrary failures, or recovery guarantees for arbitrary state-transfer interruptions. These cases are identified as future evaluation directions rather than being implied by the current results.

In summary, we clarified the separation between target-mapping construction and mapping activation, described the concurrent fence/defer/reroute path covered by the current implementation, and explicitly bounded the correctness claims to the evaluated normal-execution scenario.

Change 1. We clarified in Section 4.4 that the LB-Louvain algorithms construct the target account mapping but do not themselves perform account-state transfer or activate the new mapping. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We clarified in Section 5.7 that Fine-Grained activation is an implementation mechanism for applying an already determined target mapping and specified how affected and unaffected transactions are handled across cutover. Relevant revised manuscript text (linear notation) is as follows:

Change 3. We explicitly stated the scope of the present correctness evaluation and the failure scenarios that remain outside the current experiments. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 4. We also identify fault-injection studies of mapping activation as a direction for future evaluation. Relevant revised manuscript text (linear notation) is as follows:

Location in the revised manuscript: Section 4.4, p. 12, lines 396-397; Section 5.7, p. 20, lines 644-652; Section 6, p. 22, lines 737-739.

Comment 10:

The baseline set is too limited. Monoxide provides a relatively simple deterministic placement strategy, and CLPA is the main competitive graph-based baseline. The authors should include additional recent methods such as TxAllo, ShardCutter, workload-constrained graph partitioning, or other comparable adaptive account-placement methods wherever implementation compatibility allows.

Response 10: Thank you for this important suggestion. We agree that broader comparisons with recent adaptive account-placement methods would strengthen the evaluation when compatible implementations are available. Before extending the controlled experiments, we therefore audited the evaluated BlockEmulator codebase to determine which baselines could be executed under the same workload and system configuration.

CLPA has a compatible runnable implementation in the evaluated BlockEmulator framework and was therefore included in the new five-run controlled comparison. Monoxide is retained as a separate archived baseline because its measurements were collected on the earlier Ubuntu-based testbed rather than under the new controlled Windows configuration; we therefore do not pool the two evidence sets.

For TxAllo, ShardCutter, and workload-constrained graph-partitioning alternatives, compatible runnable implementations were not available in the evaluated codebase. We did not reimplement these methods solely for this revision because an ad hoc implementation could introduce unverified algorithmic choices, system-integration differences, and parameter assumptions, thereby producing a numerical comparison that appears controlled but is not methodologically equivalent. Instead, we strengthened the mechanism-level comparison in the Related Work section and explicitly state the implementation-compatibility limitation in the experimental setup.

Accordingly, the revised manuscript limits its controlled numerical comparison to CLPA and retains Monoxide only in the separately labeled archived evidence. We do not claim comprehensive empirical superiority over TxAllo, ShardCutter, workload-constrained graph partitioning, or all adaptive account-placement methods.

In summary, we strengthened the comparison with recent account-partitioning methods at the mechanism level, added CLPA as the compatible controlled numerical baseline, and explicitly clarified the implementation scope of the numerical baseline comparison.

Change 1. We strengthened Section 2 to provide a direct mechanism-level comparison with CLPA, TxAllo, workload-constrained graph partitioning, and ShardCutter. The corresponding revised Related Work text is described in text in our response to Comment 1 and is therefore not repeated here.

Change 2. We revised Section 5.1 to state explicitly which methods are included in the controlled numerical comparison and why the remaining recent methods are discussed at the mechanism level. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 3. Under this compatibility criterion, CLPA is included in the five-run controlled experiment reported in Section 5.2 and Figure 3, whereas the earlier Monoxide measurements remain explicitly separated as archived evidence.

Location in the revised manuscript: Section 2, pp. 3-4, lines 113-139; Section 5.1, pp. 13-14, lines 468-483; Section 5.2, pp. 14-15; Figure 3, p. 15. Archived measurements are discussed in Sections 5.5-5.6 and Figure 6 (p. 19).

Comment 11:

The reported experimental results lack sufficient statistical validation. Many conclusions are based on individual curves or specific operating points, yet no standard deviations, confidence intervals, or significance tests are reported. The authors should repeat experiments with multiple transaction segments or seeds and provide statistical variability for throughput, latency, CTR, queue dispersion, and migration-related measurements.

Response 11: Thank you for this important comment. We agree that the original presentation did not provide sufficient information about run-to-run variability. We therefore revised the controlled evaluation so that every formal controlled configuration is independently executed five times under identical system and workload settings. For these repeated runs, we report the mean, sample standard deviation, and 95% confidence interval.

Figures 3, 4, 5, and 7 now include 95% confidence-interval error bars. Figure 3 provides repeated-run variability for cross-shard transaction ratio, active throughput, confirmation latency, and peak shard-queue standard deviation; Figure 4 reports variability for the parameter- and repartitioning-sensitivity experiments; Figure 5 reports variability for partition time and cumulative allocation delta; and Figure 7 reports variability for the controlled migration/activation measurements. Thus, the principal controlled metrics requested by the reviewer are now accompanied by repeated-run uncertainty information.

We also clarify the nature of these repetitions. For a fixed input and configuration, the partitioning path uses deterministic execution. The five repetitions are therefore independent identical-configuration system executions rather than five different algorithmic random seeds or five independently sampled transaction traces. Variation across repetitions represents system-level execution variability under the same partitioning input and configuration. The workload-turnover and abrupt-shift analyses in Section 5.3 separately use contiguous segments derived from the stated 300,000-transaction workload and are labeled as such.

We did not perform a formal null-hypothesis significance test. Accordingly, the revised manuscript does not interpret the observed numerical differences as inferentially significant. We use descriptive language such as "observed," "five-run mean," and "descriptive," and the statistical reporting policy explicitly states that no statistical-significance test is claimed. The archived experiments from the original Ubuntu-based testbed are also kept separate from the new Windows controlled runs and are not pooled into the repeated-run statistical analysis.

In summary, we added a five-run statistical reporting policy for all formal controlled configurations, introduced confidence-interval error bars for the principal controlled figures, and clarified the distinction between repeated system executions and random-seed or independently resampled workload experiments.

Change 1. We revised Section 5.1 to specify the repetition procedure and statistical reporting policy. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We also summarized the repetition and statistical-reporting policy explicitly in Table 1. The entries are transcribed below:

Table 1. Controlled revision configuration and reviewer-driven experiment variations (text form).

Platform: BlockEmulator [25]; fixed.

Dataset: selectedTxs_300K.csv; fixed base workload.

Number of transactions: 300,000 by default; 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 by default; Table 1 lists 4, 8, 12, 16, 20, and 24 for the scalability experiment.

PBFT nodes per shard: 4; fixed.

Repartitioning interval: 50 s by default; 25, 50, and 100 s in the adaptation/cadence experiments.

Block interval: 5 s; fixed.

Block capacity: 2000 transactions; fixed, with byte-based block sizing disabled.

PBFT timeout: 20,000 ms; fixed.

Transaction batch size: 16,000; fixed.

Cross-shard load coefficient beta: 2.0 by default; 1.0, 1.5, 2.0, 3.0, and 4.0 in the sensitivity experiment.

Partitioning variant: M2 (complete LB-Louvain) by default; M0, M1, and M2 in the component ablation.

Configured Bandwidth parameter: 10,000,000; fixed. This is a configuration value, not an independently measured network throughput.

Operating system: Windows 11; fixed.

Implementation: Go 1.19.13; fixed.

CPU: Intel Core i9-14900HX, 24 cores and 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 standard deviation, and 95% confidence interval; no statistical-significance test is claimed.

Change 3. We added 95% confidence-interval error bars to the principal controlled experimental figures. Figures 3, 4, 5, and 7 are described in text in the preceding responses and are therefore not repeated here. Figure 3 reports the controlled baseline and component-wise ablation metrics, Figure 4 reports parameter and repartitioning sensitivity, Figure 5 reports partition-runtime and allocation profiling, and Figure 7 reports migration and activation measurements.

Change 4. We further clarified that the new repeated controlled experiments and the archived experiments from the original submission constitute separate evidence sets. Relevant revised manuscript text (linear notation) is as follows:

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.

Location in the revised manuscript: Section 5.1, p. 13, lines 452-473; Table 1, p. 14; Figures 3, 4, 5, and 7 on pp. 15, 16, 18, and 20, respectively; Section 5.7, p. 21, lines 661-668.

Comment 12:

The scalability evidence remains limited. Although up to 24 shards are simulated, all shards run within BlockEmulator on a single workstation, using one Ethereum transfer dataset. This does not fully represent geographically distributed blockchain nodes, heterogeneous network delays, failures, consensus variability, or much larger account graphs. Additional datasets and, ideally, experiments on a distributed physical or cloud testbed would strengthen the practical claims considerably.

Response 12: Thank you for this important comment. We agree that the current BlockEmulator evaluation does not constitute geographically distributed or production-scale validation. We have therefore bounded the practical claims to the configurations actually evaluated in this study. The new controlled experiments were conducted on a single Windows 11 workstation with an Intel Core i9-14900HX processor, 31.73 GB of memory, and 4-24 emulated physical shards. The controlled workload is the 300,000-transaction selectedTxs_300K.csv Ethereum-transfer trace distributed with BlockEmulator. Accordingly, these experiments should be interpreted as controlled emulation evidence rather than as measurements from geographically distributed blockchain nodes or a heterogeneous WAN deployment.

Within this controlled scope, we added two complementary forms of scalability evidence. First, Figure 5 profiles the complete partitioning path over transaction prefixes from 50,000 to 300,000 and physical-shard counts from 4 to 24. Across all evaluated combinations, the measured partition time remains below 100 ms. Second, the migration/activation experiment in Figure 7 and Table 2 measures the complete reconfiguration path: the mean total reconfiguration times range from approximately 7.90 to 8.62 s across the three evaluated activation modes and remain below the configured 50-s repartitioning interval. These results show that periodic repartitioning is feasible within the tested implementation range, but they are not used to infer the same behavior for much larger account graphs or distributed deployments.

We also make the dataset scope explicit. The controlled experiments use one fixed 300,000-transaction historical Ethereum workload. The broader archived experiments provide additional coverage over transaction arrival rates and shard counts, but they are derived from the same overall experimental framework and do not constitute validation on independent blockchain workloads. We therefore do not claim that the present results establish workload-independent or cross-platform generality.

Finally, we identify independent workloads, additional blockchain platforms, geographically distributed deployments, and fault-injection studies as directions for further evaluation. In particular, heterogeneous network behavior, distributed consensus variability, and failure scenarios require a distributed or fault-injected evaluation environment beyond the controlled single-host experiments reported here.

In summary, we clarified the experimental scope, added implementation-level scalability and complete-reconfiguration measurements within the controlled environment, avoided extrapolating these results to production-scale or geographically distributed deployments, and identified broader workload and distributed-system validation as future work.

Change 1. We revised Section 5.1 to report the controlled testbed and workload explicitly, thereby making the scope of the scalability evidence clear. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We clarified in the Discussion that the partitioning-cost measurements characterize only the evaluated workload and shard-count ranges and are not extrapolated to asymptotic or production-scale performance. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 3. Figure 5, which provides the corresponding five-run partition-time and allocation profiles over 50,000-300,000 transaction prefixes and 4-24 physical shards, is described in text in our response to Comment 7 and is therefore not repeated here.

Change 4. We also report the complete measured reconfiguration cost, rather than relying only on partition-computation time. Figure 7 and Table 2 are described in text in our response to Comment 8. The corresponding revised discussion at the end of Section 5.7 is as follows:

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.

Change 5. We explicitly identify broader workload, platform, distributed-deployment, and fault-injection evaluations as future work. Relevant revised manuscript text (linear notation) is as follows:

Location in the revised manuscript: Section 5.1, pp. 12-14, lines 428-485; Section 5.4, p. 17, lines 561-581, and Figure 5 (p. 18); Section 5.7, pp. 20-21, and Table 2 (p. 21); Section 5.8, p. 22, lines 711-714; Section 6, p. 22, lines 737-739.

We thank the reviewer again for the constructive comments and for helping us improve the manuscript.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

The authors demonstrate a load-aware account-partitioning method for account-based state sharding. Standard Louvain is used to extract logical communities, after which load-aware community assignment and boundary-account refinement construct the final account mapping. The approach is interesting and experiments a reduction in cross-shard transactions and shard-level workload concentration while improving throughput and latency.

First, the experiments were conducted on BlockEmulator with historical Ethereum transactions. Please discuss better the implications, what are the limitations, and discuss the generality of the obtained solutions. Particularly for other platforms. Second, the figures should also show the statistical confidence - was it chance?

Author Response

Dear Reviewer 2,

We sincerely thank you for your careful review and valuable comments regarding the generality of the BlockEmulator/Ethereum evaluation and the statistical reliability of the experimental results. We have carefully considered all of your comments and revised the manuscript accordingly. All substantive revisions are highlighted in red in the revised manuscript to facilitate verification. Our point-by-point responses are provided below.

Comment 1:

The experiments were conducted on BlockEmulator with historical Ethereum transactions. Please discuss better the implications, what are the limitations, and discuss the generality of the obtained solutions. Particularly for other platforms.

Response 1: Thank you for this important comment. We agree that the implications and generality of the BlockEmulator/Ethereum evaluation should be stated more explicitly. The revised manuscript therefore distinguishes between the general account-placement principle investigated by LB-Louvain and the specific blockchain execution model under which the current empirical results were obtained.

At the methodological level, LB-Louvain addresses an account-based state-sharding setting in which historical account interactions can be represented as a weighted graph and logical interaction communities must ultimately be mapped onto a fixed set of physical shards. The coarse-to-fine idea - preserving densely interacting accounts at the community level, dispersing community activity across physical shards, and then refining boundary accounts - can in principle be adapted to other account-based systems that expose comparable interaction and shard-load information. However, the present implementation and evaluation should not be interpreted as demonstrating platform-independent performance.

Specifically, the current experiments use BlockEmulator as a controlled emulation environment and replay one fixed 300,000-transaction historical Ethereum transfer workload. The resulting graph contains 54,403 unique accounts and 64,378 undirected weighted account-pair edges. The evaluated model aggregates transfer directions into an undirected interaction graph for partitioning and uses the relay-based cross-shard execution model implemented in BlockEmulator. Consequently, the reported results characterize the evaluated Ethereum-transfer workload and emulator configuration rather than a production blockchain deployment or universal behavior across blockchain platforms.

Other platforms may expose different transaction semantics and cost structures. For example, direction-specific sender/recipient roles, smart-contract read/write access sets, platform-specific state representations, different consensus mechanisms, or different cross-shard communication paths may require a directed or role-aware interaction representation, a richer access graph, and recalibration of the shard-load model. The revised manuscript therefore makes these modeling assumptions explicit rather than assuming that the present graph and load model can be transferred unchanged to every blockchain platform. The current manuscript already states that direction-specific access behavior is not explicitly represented by the undirected partitioning graph.

We have also bounded the empirical claims accordingly. The controlled scalability results characterize only the tested BlockEmulator implementation range and are not used to infer asymptotic or production-scale behavior. Independent workloads, additional blockchain platforms, directed and smart-contract access patterns, geographically distributed deployments, and fault-injection studies are now identified explicitly as directions for further evaluation.

In summary, we clarified the scope of the current Ethereum/BlockEmulator evidence, made the assumptions of the interaction and execution models explicit, bounded the generality claims to the evaluated setting, and identified the changes and additional validation that would be required for broader blockchain platforms.

Change 1. We revised Section 3.2 to clarify what information is represented by the current interaction graph and which direction-specific behaviors remain outside the present partitioning model. Relevant revised manuscript text (linear notation) is as follows:

Change 2. We expanded Section 5.1 to report the exact controlled workload and its available provenance, thereby making the empirical scope of the results explicit. Relevant revised manuscript text (linear notation) is as follows:

Change 3. We also revised the Data Availability Statement to identify the exact workload used in the controlled evaluation. Relevant revised manuscript text (linear notation) is as follows:

Data Availability Statement: The controlled experiments use the publicly available selectedTxs_300K.csv workload distributed in the BlockEmulator repository (accessed on 3 September 2026). BlockEmulator identifies this workload as derived from XBlock-ETH; the exact file's SHA-256 checksum and the provenance information available from the upstream project are reported in Section 5.1.

Change 4. We further clarified in the Discussion that the measured scalability behavior applies to the evaluated implementation range and is not extrapolated to production-scale systems. Relevant revised manuscript text (linear notation) is as follows:

Change 5. We explicitly identify broader workloads, additional blockchain platforms, richer access patterns, and distributed deployments as future evaluation directions. Relevant revised manuscript text (linear notation) is as follows:

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.

Location in the revised manuscript: Section 3.2, pp. 5-6; Section 5.1, p. 13, lines 438-451; Section 5.8, p. 22, lines 711-714; Section 6, p. 22, lines 735-739; Data Availability Statement, p. 23, lines 748-751.

Comment 2:

The figures should also show the statistical confidence - was it chance?

Response 2: Thank you for this important comment. We agree that the figures should show run-to-run uncertainty so that the reported differences are not presented as isolated single-run observations. We therefore repeated every formal controlled configuration five times as an independent system execution under identical workload and system settings and report the mean, sample standard deviation, and 95% confidence interval based on these five runs.

The principal controlled figures have been revised accordingly. Figures 3, 4, 5, and 7 now include 95% confidence-interval error bars. Figure 3 reports uncertainty for the controlled baseline comparison and component-wise ablation, including cross-shard transaction ratio, active throughput, average confirmation latency, and peak shard-queue standard deviation. Figure 4 reports uncertainty for the cross-shard load-coefficient and repartitioning-interval sensitivity experiments. Figure 5 reports uncertainty for partition runtime and cumulative allocation profiling, and Figure 7 reports uncertainty for the controlled mapping-activation and migration measurements. The corresponding figure captions explicitly state that the error bars denote 95% confidence intervals over five repeated runs.

We also clarified what these repetitions represent. For a fixed input and configuration, the partitioning path uses deterministic execution. The five repetitions are therefore independent identical-configuration system runs rather than different algorithmic random seeds or five independently sampled transaction traces. Consequently, the reported intervals characterize system-level execution variability under the same partitioning input and configuration.

We did not perform a formal null-hypothesis significance test. Accordingly, the revised manuscript does not claim that the observed differences are statistically significant in an inferential sense. We report the observed differences descriptively together with their repeated-run variability. This distinction is also reflected explicitly in the manuscript; for example, the migration comparison states that the differences are interpreted descriptively and that no statistical-significance test is claimed.

Finally, the archived Figure 6 is intentionally kept separate from this statistical treatment. Those operating points were obtained in the earlier Ubuntu-based experiments and are not pooled with the new Windows controlled runs. The revised manuscript therefore distinguishes repeated controlled evidence from the broader archived evidence rather than presenting all figures as if they had been generated under one statistical experiment.

In summary, we added repeated controlled measurements, statistical variability reporting, and 95% confidence-interval error bars to the principal controlled figures, while explicitly distinguishing repeated system runs from random-seed experiments and avoiding unsupported statistical-significance claims.

Change 1. We revised Section 5.1 to specify how the controlled experiments are repeated and how statistical uncertainty is reported. Relevant revised manuscript text (linear notation) is as follows:

Change 2. We also summarized the formal repetition and statistical-reporting policy in Table 1. The entries are transcribed below:

Table 1. Controlled revision configuration and reviewer-driven experiment variations (text form).

Platform: BlockEmulator [25]; fixed.

Dataset: selectedTxs_300K.csv; fixed base workload.

Number of transactions: 300,000 by default; 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 by default; Table 1 lists 4, 8, 12, 16, 20, and 24 for the scalability experiment.

PBFT nodes per shard: 4; fixed.

Repartitioning interval: 50 s by default; 25, 50, and 100 s in the adaptation/cadence experiments.

Block interval: 5 s; fixed.

Block capacity: 2000 transactions; fixed, with byte-based block sizing disabled.

PBFT timeout: 20,000 ms; fixed.

Transaction batch size: 16,000; fixed.

Cross-shard load coefficient beta: 2.0 by default; 1.0, 1.5, 2.0, 3.0, and 4.0 in the sensitivity experiment.

Partitioning variant: M2 (complete LB-Louvain) by default; M0, M1, and M2 in the component ablation.

Configured Bandwidth parameter: 10,000,000; fixed. This is a configuration value, not an independently measured network throughput.

Operating system: Windows 11; fixed.

Implementation: Go 1.19.13; fixed.

CPU: Intel Core i9-14900HX, 24 cores and 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 standard deviation, and 95% confidence interval; no statistical-significance test is claimed.

Change 3. We revised the principal controlled figures to display statistical uncertainty directly. The corresponding captions now state the confidence-interval interpretation of the error bars.

For Figure 3, the revised caption states: Error bars denote 95% confidence intervals over five repeated system runs.

For Figure 4, the revised caption states: Error bars denote 95% confidence intervals over five repeated system runs.

For Figure 5, the revised caption states: The allocation metric is the measured cumulative allocation delta during the partitioning procedure rather than peak resident memory. Error bars denote 95% confidence intervals over five repeated profiling runs under identical configurations.

For Figure 7, the revised caption states: Error bars denote 95% confidence intervals over five repeated system runs.

Change 4. We also clarified that the repeated-run confidence intervals are used to characterize experimental variability and are not presented as formal hypothesis-test results. The revised text includes the following statement:

These differences are interpreted descriptively; no statistical-significance test is claimed.

Change 5. We further clarified that the new five-run controlled experiments and the archived experiments from the original submission are treated as separate evidence sets. Relevant revised manuscript text (linear notation) is as follows:

Location in the revised manuscript: Section 5.1, p. 13, lines 452-473; Table 1, p. 14; Figures 3, 4, 5, and 7 on pp. 15, 16, 18, and 20, respectively; Section 5.7, p. 21, lines 661-668; Sections 5.5-5.6 and archived Figure 6 (p. 19).

We thank the reviewer again for the constructive comments and for helping us improve the manuscript.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

REVIEW of the manuscript

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

The manuscript addresses the relevant problem of optimizing account placement in a state-sharded blockchain system. To determine the placement of accounts among physical shards, the authors propose a three-stage heuristic approach: extracting logical communities using the standard Louvain algorithm; assigning the resulting communities to physical shards while taking their loads into account; and subsequently moving boundary accounts locally when such a move reduces the maximum load across the two shards involved.

The experiments were conducted in BlockEmulator by replaying real Ethereum transactions from the XBlock-ETH dataset.

The manuscript is generally logically structured, the method is described sufficiently consistently, and the results are presented clearly; therefore, the paper is easy to read. However, these strengths do not compensate for the limited scientific novelty of the results and the lack of convincing evidence of the practical applicability of the proposed method. Detailed comments are provided below.

The scientific novelty of LB-Louvain is insufficiently justified

In the Related Work section (pp. 2–4, lines 49–135), the authors themselves note that previous studies have already proposed methods for placing accounts across shards that simultaneously consider transaction locality and load balance among physical shards. These methods include CLPA, TxAllo, and ShardCutter. In the first stage of LB-Louvain, the standard Louvain algorithm is used without modification: the authors change neither the modularity criterion nor the procedures for moving vertices between communities and subsequently aggregating communities (p. 7, lines 227–252). The authors’ new proposal consists of adding two further stages to Louvain: assigning communities to shards and locally moving individual boundary accounts (pp. 8–10, lines 253–341). Both added stages are implemented using relatively simple algorithms, yet the authors do not explain which specific elements of these algorithms are novel. The authors call this combination of three stages a new method, LB-Louvain.

The proposed composition of procedures appears more like an engineering solution than a new scientific result. Therefore, the authors should first explain what exactly in their work constitutes a new scientific result, especially in comparison with the most closely related methods, such as CLPA and ShardCutter. Why does combining standard Louvain with two simple procedures constitute scientific novelty rather than merely a heuristic approach? An experimental demonstration of better values for some metrics alone is insufficient to justify scientific novelty, especially because the experimental results themselves also raise substantial concerns.

The claimed trade-off between transaction locality and load balance is not formally defined, and the corresponding optimization problem is not formulated

On pp. 5–6, the authors introduce two quantities—the cross-shard transaction ratio CTR(P) and the normalized load dispersion D(P)/L(P)—and then write them as components of the vector J(P) in Equation (9). However, writing two metrics as components of a vector merely lists the evaluation criteria and does not define an optimization problem or a rule for selecting a solution. Therefore, the claim that the proposed problem formulation ‘explicitly captures the tradeoff’ (p. 3, lines 72–75) is insufficiently justified: the paper does not define what this trade-off consists of or by what rule it is to be achieved.

Moreover, the boundary-account rebalancing stage permits moves that reduce the local maximum load but may simultaneously increase CTR(P); the authors explicitly state that a monotonic decrease in CTR(P) is not required (p. 10, lines 323–333). However, the paper does not specify how much the cross-shard transaction ratio may increase as a result of such moves or under what conditions such an increase is considered acceptable in view of the simultaneous reduction in load imbalance among physical shards. Therefore, the concept of the trade-off and the rule for selecting a compromise solution must be formalized.

When selecting a shard, the interaction intensity between the community being placed and previously placed communities is not taken into account

In Algorithm 1, the K most active communities are first assigned to distinct physical shards, and each subsequent community is assigned to the shard with the lowest load before its addition (pp. 8–9, lines 268–292). When selecting a shard, the algorithm does not analyze how the shard loads and CTR(P) would change if the current community were placed in each possible shard.

As a result, communities with a large number of transactions between them may be placed in different shards. This may simultaneously increase the number of cross-shard transactions and the aggregate load, because a cross-shard transaction is processed by two shards. The authors should either justify this community-assignment rule or account for the intensity of interactions between communities when selecting shards for their placement.

The execution order, termination conditions, and time complexity of the algorithms are insufficiently specified

In the description of the standard Louvain algorithm (p. 7, lines 238–242), the vertex traversal order and the selection rule when several moves yield the same modularity gain remain unspecified. For Algorithm 1, the authors state that when several shards have the same minimum load, one of them is selected deterministically (p. 8, line 278), but the selection rule itself is not given. Algorithm 2 uses the underspecified command ‘Select one such account’, and the rule for choosing among several destinations with the same maximum gain is also absent (p. 10). Since greedy algorithms may produce different results depending on the order in which elements are processed, these details are important.

In Algorithm 2, after each accepted move of account v_i, all accounts adjacent to v_i in the transaction graph are marked again as requiring examination. However, the authors do not prove termination of this procedure or provide an upper bound on the number of repeated examinations or moves. In Equation (19), the complexity is expressed in terms of r1 and r2—the numbers of edge-processing passes during Louvain and boundary rebalancing, respectively (p. 11, lines 342–362). These quantities depend on the graph structure and the sequence of accepted moves, but neither their upper bounds nor their experimental values are provided. Therefore, Equation (19) does not provide an upper bound on the running time as a function of graph size and, consequently, does not support a substantiated conclusion about the scalability of the method.

The effect of the individual stages of LB-Louvain on the reported experimental results is not investigated

All experimental results are reported for the complete three-stage algorithm. On p. 13, lines 402–404, the authors explicitly state that the observed improvements are not attributed to any individual stage. Therefore, it is impossible to determine the contribution of each stage to the improved results. This is important: if approximately the same results can be achieved without the second or third stage, the need for that stage remains unjustified.

At a minimum, the following variants should be compared: standard Louvain with a baseline community assignment; Louvain with the proposed community assignment but without boundary rebalancing; and the complete LB-Louvain with community assignment and boundary rebalancing. Without such an analysis, the experiments do not confirm the usefulness of the particular components that the authors add to Louvain and present as their own scientific contribution.

The experimental validation is insufficient to support the claimed advantages, and the description of the experiments is insufficient to reproduce the results

Only Monoxide and CLPA are used as baselines for the experimental comparison with LB-Louvain (p. 11, lines 380–385). Monoxide does not use adaptive account placement based on the transaction graph, so a substantial advantage over it is expected. At the same time, the Related Work section discusses other methods, such as TxAllo, ShardCutter, workload-constrained graph partitioning, and LB-Chain, but no experimental comparison with them is provided.

Furthermore, the exact portion of XBlock-ETH, the dates or block numbers, the number of unique accounts and graph edges, the transaction-preprocessing rules, and the Louvain implementation parameters are not specified. It is also not stated which particular combination of transaction arrival rate and shard count produced the results shown in Figure 3. The authors explicitly state that the implementation code is not publicly available (p. 11, line 373), and no supplementary materials containing the code are provided. Under these conditions, the results are practically impossible to reproduce independently.

The practical applicability of the method has not been demonstrated

In the experimental configuration, repartitioning is triggered every 50 seconds (pp. 11–12). However, the authors do not report the time required to construct the graph, run Louvain, assign the communities, and perform boundary rebalancing. Moreover, Algorithms 1 and 2 only construct the target mapping and do not transfer account states (p. 10, lines 340–341), while the time required by the Transaction-Aware Activation procedure to actually migrate account states to their newly assigned shards is not reported. It is therefore unclear whether the entire repartitioning cycle, including state migration, can be completed within 50 seconds, especially for graphs containing millions of accounts and transactions.

Conclusion: In its current form, the manuscript cannot be recommended for publication. Substantial revision of the manuscript requires the authors to:

- explain and justify the scientific novelty of the proposed approach;

- provide evidence that the method can be applied in practice;

- formally define the optimization problem and the rule for reconciling the cross-shard transaction ratio with load imbalance among physical shards;

- specify the execution order of the algorithms, the selection rules when several equivalent alternatives are available, and the termination conditions;

- substantially expand the experimental evaluation by adding an analysis of the contribution of the individual stages, comparisons with other closely related methods, measurements of running time, and the costs of actual state migration.

Recommended decision: Major Revision.

Author Response

Dear Reviewer 3,

We sincerely thank you for your rigorous and detailed assessment of our manuscript. We have carefully considered all of your comments and revised the manuscript to clarify the scientific contribution, formalize the role of the proposed stages, strengthen the component-wise evaluation, improve reproducibility reporting, and provide additional evidence regarding computational and reconfiguration costs. All substantive revisions are highlighted in red in the revised manuscript to facilitate verification. Our point-by-point responses are provided below.

Comment 1:

The scientific novelty of LB-Louvain is insufficiently justified.

In the Related Work section (pp. 2-4, lines 49-135), the authors themselves note that previous studies have already proposed methods for placing accounts across shards that simultaneously consider transaction locality and load balance among physical shards. These methods include CLPA, TxAllo, and ShardCutter. In the first stage of LB-Louvain, the standard Louvain algorithm is used without modification: the authors change neither the modularity criterion nor the procedures for moving vertices between communities and subsequently aggregating communities (p. 7, lines 227-252). The authors' new proposal consists of adding two further stages to Louvain: assigning communities to shards and locally moving individual boundary accounts (pp. 8-10, lines 253-341). Both added stages are implemented using relatively simple algorithms, yet the authors do not explain which specific elements of these algorithms are novel. The authors call this combination of three stages a new method, LB-Louvain.

Response 1: Thank you for this fundamental comment. We agree that the scientific contribution of LB-Louvain must not be justified by presenting standard Louvain itself as new, nor by claiming that jointly considering transaction locality and shard-load balance is a new objective. We have therefore revised the manuscript to state explicitly that LB-Louvain is a coarse-to-fine account-partitioning heuristic and that standard Louvain is used only as the logical-community extraction stage.

The specific contribution addressed in this work arises from the fixed-physical-shard placement problem that remains after graph-dependent communities have been extracted. Standard Louvain determines the number, size, and activity of logical communities from the interaction graph, whereas the blockchain system has a prescribed number of physical shards. The resulting community labels therefore cannot be used directly as physical-shard identifiers, and heterogeneous community activity may still create workload concentration even when the internal interaction structure of each community is preserved. The revised manuscript makes this mismatch explicit and treats it as the motivation for the two subsequent LB-Louvain stages.

The LB-Louvain-specific construction is therefore not a modification of the Louvain modularity algorithm. Instead, it is a staged physical-placement procedure. The first proposed stage retains each detected logical community as an indivisible coarse placement unit and distributes communities according to estimated physical-shard load. The second proposed stage then restricts account-level correction to boundary accounts and to candidate shards associated with observed transaction neighbors, accepting movements according to the local source-destination load-improvement rule. The purpose of this coarse-to-fine construction is to separate the preservation of dense interaction structure from coarse load dispersion and subsequent fine-grained correction, rather than attempting to solve all three decisions inside the Louvain objective itself.

We also strengthened the comparison with the closest related graph-based methods. CLPA, which is used as the controlled graph-based baseline in our evaluation, formulates cross-shard activity and workload balance as a network-partitioning problem. ShardCutter integrates community-aware partitioning with state migration, while TxAllo and workload-constrained graph-partitioning methods also jointly consider transaction relationships and workload. The distinction claimed for LB-Louvain is therefore not the general goal of balancing locality and load, but the specific use of graph-dependent Louvain communities as coarse locality-preserving placement units, their subsequent mapping onto a fixed physical-shard set according to estimated load, and the restricted boundary-account refinement that follows. The revised Related Work now states this positioning explicitly.

Finally, we agree with the reviewer that better end-to-end metrics alone cannot establish scientific novelty. We therefore added the M0/M1/M2 component-wise ablation not as the sole basis for the novelty claim, but as empirical evidence that the two LB-Louvain-specific stages have distinguishable operational roles. M0 provides the standard-Louvain-based physical-placement baseline, M1 isolates the effect of load-aware community assignment, and M2 adds boundary refinement. The results show that Stage 2 primarily improves shard-load balance, whereas Stage 3 primarily recovers transaction locality while preserving the load-balance improvement. Thus, the revised contribution is supported by both an explicit methodological distinction and a component-wise evaluation of that staged design.

In summary, we revised the manuscript to narrow and clarify the novelty claim, distinguish standard Louvain from the LB-Louvain-specific physical-placement stages, strengthen the comparison with closely related graph-based methods, and provide component-wise evidence for the distinct roles of the proposed stages.

Change 1. We revised the Abstract to describe LB-Louvain explicitly as a coarse-to-fine account-partitioning heuristic and to identify the three stages without attributing novelty to standard Louvain. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We revised the Introduction to state the contribution in terms of the fixed-shard placement formulation, the two LB-Louvain-specific refinement stages, and their controlled evaluation. Relevant revised manuscript text (linear notation) is as follows:

The main contributions are as follows:

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;

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;

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.

Change 3. We strengthened the Related Work section to distinguish the proposed construction from closely related graph-based and load-aware account-partitioning methods. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 4. We revised the method description to make explicit why standard Louvain does not by itself produce a valid physical-shard mapping and where the LB-Louvain-specific processing begins. Relevant revised manuscript text (linear notation) is as follows:

The resulting logical-community set is

C = {C_1, C_2,..., C_R},

Change 5. We further expanded the design rationale to explain why the three stages have different responsibilities. Relevant revised manuscript text (linear notation) is as follows:

Change 6. To verify that the two LB-Louvain-specific stages have distinguishable effects rather than functioning as an opaque combined pipeline, we added the controlled M0/M1/M2 component-wise ablation in Section 5.2.

Location in the revised manuscript: Abstract, p. 1, lines 8-10; Introduction, p. 3, lines 69-85; Section 2, pp. 3-4, lines 113-139; Section 4.1, p. 7, lines 253-261; Section 4.2, p. 8, lines 274-291; Section 5.2, pp. 14-15, lines 487-512, and Figure 3 (p. 15).

Comment 2:

The claimed trade-off between transaction locality and load balance is not formally defined, and the corresponding optimization problem is not formulated.

On pp. 5-6, the authors introduce two quantities - the cross-shard transaction ratio CTR(P) and the normalized load dispersion D(P)/L_avg(P) - and then write them as components of the vector J(P) in Equation (9). However, writing two metrics as components of a vector merely lists the evaluation criteria and does not define an optimization problem or a rule for selecting a solution. Therefore, the claim that the proposed problem formulation 'explicitly captures the tradeoff' (p. 3, lines 72-75) is insufficiently justified: the paper does not define what this trade-off consists of or by what rule it is to be achieved.

Moreover, the boundary-account rebalancing stage permits moves that reduce the local maximum load but may simultaneously increase CTR(P); the authors explicitly state that a monotonic decrease in CTR(P) is not required (p. 10, lines 323-333). However, the paper does not specify how much the cross-shard transaction ratio may increase as a result of such moves or under what conditions such an increase is considered acceptable in view of the simultaneous reduction in load imbalance among physical shards. Therefore, the concept of the trade-off and the rule for selecting a compromise solution must be formalized.

Response 2: Thank you for this important comment. We agree with the reviewer that writing CTR(P) and normalized load dispersion as the two components of J(P) does not by itself define a multi-objective optimization problem or a rule for selecting a compromise solution. We have therefore revised the manuscript to clarify that Equation (9) is a criterion vector used to characterize feasible mappings along two competing evaluation dimensions, rather than a scalar optimization objective.

LB-Louvain does not combine the two criteria through a fixed weighted sum and does not solve an enumerated Pareto optimization problem. Instead, the compromise is implemented operationally through the staged heuristic. Standard Louvain first preserves dense historical interaction structure at the community level. Stage 2 retains these communities as coarse placement units and disperses them according to estimated shard load. Stage 3 then performs restricted account-level correction. For a boundary account v_i, candidate destination shards are limited to shards containing observed transaction neighbors. For each candidate s_b, the method evaluates the reduction Delta L_(i,b) in the maximum estimated load of the corresponding source-destination shard pair. A movement is accepted only if Delta L_(i,b) > 0, and when several candidates provide a positive reduction, the candidate with the largest load improvement is selected. If no candidate provides a positive gain, the account remains on its current shard.

We also clarify explicitly that Stage 3 does not impose a separate numerical upper bound on the increase of global CTR(P) caused by an individual accepted movement. Thus, an individual movement is not accepted because its CTR increase is below some hidden threshold; it is accepted according to the formal load-improvement rule above, while candidate destinations remain restricted to observed neighbor shards and changes in cross-shard processing are incorporated into the source- and destination-shard load estimates through Ex_k(P). Accordingly, the method should be interpreted as a staged locality-load heuristic rather than as a solver with a guaranteed Pareto-optimal or globally optimal solution.

We further quantified the resulting empirical compromise using the controlled M0/M1/M2 ablation. Relative to M0, M1 reduces the peak shard-queue standard deviation by approximately 12.53%, while the cross-shard transaction ratio increases by approximately 0.73%, showing the locality cost associated with the Stage-2 load-balance improvement. 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%. Thus, although individual Stage-3 movements are not constrained to monotonically decrease global CTR, the complete Stage-3 refinement produces a net recovery of transaction locality in the evaluated controlled experiment while largely preserving the load-balance improvement obtained by Stage 2.

In summary, we revised the formulation to distinguish the two evaluation criteria from a scalar optimization objective, formalized the operational compromise rule used by the staged heuristic, clarified that no independent global-CTR increase threshold is imposed on individual boundary movements, and quantified the observed locality-load compromise through the component-wise ablation.

Change 1. Clarification of the contribution statement. The Introduction motivates the locality-load tradeoff, while Sections 3.3 and 4.1 state how it is represented and addressed. Our intended interpretation is as follows:

The fixed-shard formulation characterizes historical transaction locality and shard-load balance as two competing evaluation criteria while preserving unique account-to-shard ownership. Equation (9) evaluates feasible mappings; it does not itself specify a scalar objective or prove that a multi-objective optimum is obtained.

LB-Louvain coordinates these criteria through load-aware community-to-shard assignment and restricted boundary-account rebalancing while using standard Louvain to preserve coarse interaction structure. This is a clarification of the contribution claim, rather than a quotation of replacement wording in the Introduction.

Change 2. We clarified in Sections 3.3 and 4.1 that Equation (9) characterizes two evaluation dimensions and that LB-Louvain coordinates them through a staged heuristic rather than a fixed scalar objective. Relevant revised manuscript text (linear notation) is as follows:

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

J(P) = (CTR(P), D(P)/L_avg(P)), P in F; F = {P: V -> S | P satisfies (4)}. (9)

where smaller values of the first and second components indicate better historical transaction locality and a more balanced shard-load distribution, respectively.

Change 3. We formalized the boundary-account decision rule in Section 4.4 by defining the candidate-shard set and the load-improvement condition used to accept a movement. Relevant revised manuscript text (linear notation) is as follows:

For each v_i in B(P), candidate destinations are restricted to the distinct shards hosting its external neighbors:

N_S(v_i; P) = {P(v_j) in S | v_j in N(v_i), P(v_j)!= P(v_i)}.

Suppose v_i currently belongs to source shard s_a = P(v_i), and s_b in N_S(v_i; P) is a candidate destination. Let P_(i->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

L_old(i,b) = max{L_a(P), L_b(P)}; L_new(i,b) = max{L_a(P_(i->b)), L_b(P_(i->b))}; Delta L_(i,b) = L_old(i,b) - L_new(i,b).

s_i* in argmax_{s_b in N_S(v_i; P), Delta L_(i,b) > 0} Delta L_(i,b).

If no candidate produces a positive gain, v_i remains on its current shard.

Change 4. We further clarified how cross-shard effects are treated when evaluating an accepted movement. Relevant revised manuscript text (linear notation) is as follows:

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 Ex_k, while an edge that changes from cross-shard to intra-shard is incorporated into the updated 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).

Change 5. We quantified the observed locality-load compromise through the controlled component-wise ablation in Section 5.2. Figure 3 is described in text in our response to Comment 1 and is therefore not repeated here. The relevant result is as follows:

Location in the revised manuscript: Section 3.3, p. 7, lines 233-243, Equation (9); Section 4.1, p. 7, lines 246-261; Section 4.4, pp. 10-11, lines 349-376, Equations (16)-(18); Section 5.2, pp. 14-15, lines 503-512, and Figure 3 (p. 15).

Comment 3:

When selecting a shard, the interaction intensity between the community being placed and previously placed communities is not taken into account.

In Algorithm 1, the K most active communities are first assigned to distinct physical shards, and each subsequent community is assigned to the shard with the lowest load before its addition (pp. 8-9, lines 268-292). When selecting a shard, the algorithm does not analyze how the shard loads and CTR(P) would change if the current community were placed in each possible shard.

Response 3: Thank you for this important comment. We agree that Algorithm 1 does not evaluate every candidate physical shard according to a combined interaction-intensity and load objective before placing the current community. This is an intentional design choice of Stage 2 rather than an omitted step in the implementation. Equation (13) and Algorithm 1 specify the least-loaded-shard rule, and we explain its scope and consequences below.

Stage 1 has already used the weighted transaction graph to group accounts with dense historical interactions into logical communities. Stage 2 therefore keeps each detected community intact as a coarse-grained placement unit and focuses on dispersing community activity across the configured physical shards. Communities are processed in nonincreasing weighted-activity order, and after the initial shard initialization, each remaining community is assigned to the currently least-loaded shard. The role of this stage is coarse load dispersion while preserving the dense interaction structure already captured inside each Louvain community; it is not intended to perform an exhaustive interaction-aware search over all possible community-to-shard placements.

Importantly, inter-community transaction relationships are not discarded from the load model. Once the endpoint communities of an inter-community edge have both been assigned, the edge is classified according to the resulting physical placement. If both communities are placed on the same physical shard, its weight contributes to the corresponding intra-shard load; if they are placed on different physical shards, it contributes to the cross-shard loads of both participating shards. Therefore, although the interaction intensity with previously placed communities is not used as an additional candidate-selection objective for the current community, the processing consequence of that placement is incorporated into the maintained shard loads and can affect the placement of subsequent communities.

We deliberately do not introduce an additional candidate-specific weighted objective combining inter-community interaction intensity and shard load in Stage 2. Doing so would require defining another rule for trading locality against load at the community-placement level and would change the present staged heuristic into a different placement algorithm. Instead, LB-Louvain separates the two granularities: Stage 2 performs coarse load-aware placement while keeping communities intact, and Stage 3 subsequently provides restricted account-level correction for residual locality and load effects at community boundaries.

The component-wise ablation supports this intended division of responsibility. Relative to M0, adding Stage 2 reduces the peak shard-queue standard deviation by approximately 12.53%, while increasing the cross-shard transaction ratio by approximately 0.73%. Adding Stage 3 then reduces the cross-shard transaction ratio by approximately 0.92%, while changing the peak queue standard deviation by only approximately 0.46%. Thus, the controlled results directly expose the locality cost of the Stage-2 least-loaded placement rule and the subsequent locality recovery provided by Stage 3, rather than concealing this design trade-off.

Change 1. We revised Section 4.3 to clarify the role of community activity and the purpose of the least-loaded-shard placement rule. Relevant revised manuscript text (linear notation) is as follows:

The second stage treats each detected community as an indivisible coarse-grained placement unit. A community-to-shard mapping phi: C -> 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 ell(C_r) denote the weighted activity of community C_r. It is calculated from the weighted degrees of its accounts. The communities are processed in nonincreasing activity order:

ell(C_r) = sum_(v_i in C_r) d_i; ell(C_(1)) >= ell(C_(2)) >=... >= ell(C_(R)).

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).

Change 2. We explicitly state the coarse placement rule used after the initial shard assignment. Relevant revised manuscript text (linear notation) is as follows:

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 >= K, the first K communities are used to initialize the K physical shards.

Let L_hat_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:

phi(C_(r)) in argmin_(s_k in S) L_hat_k, r > q.

Change 3. To clarify the scope of the Stage-2 rule in response to the reviewer, we explain its operation below. The relevant manuscript basis is Equation (13), Algorithm 1, and the accompanying load-update discussion in Section 4.3:

The least-loaded-shard rule in (13) is intentionally load-oriented. For the current community, Stage 2 does not evaluate every candidate shard using an additional interaction-intensity or predicted- CTR objective. Instead, the dense interaction structure identified within each Louvain community is preserved by keeping the community intact, while coarse placement prioritizes dispersion of estimated processing load. Inter-community edges are retained in the subsequent load updates, and residual locality effects are addressed by the boundary-account refinement in Section 4.4. Thus, Algorithm 1 should be interpreted as a coarse load-placement stage rather than as a globally interaction-aware community-assignment optimizer.

Change 4. We clarified how inter-community transaction relationships enter the load accounting after community placement. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 5. We further clarified why the coarse community placement is followed by boundary-account refinement. Relevant revised manuscript text (linear notation) is as follows:

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^(0) is therefore passed to boundary-account rebalancing.

Change 6. We quantified the observed effect of this design through the component-wise ablation in Section 5.2. Figure 3 is described in text in our response to Comment 1 and is therefore not repeated here. The relevant result is as follows:

Location in the revised manuscript: Section 4.3, pp. 8-10, lines 293-340, Equations (12)-(14) and Algorithm 1 (p. 9); Section 4.4, pp. 10-12; Section 5.2, pp. 14-15, lines 503-512, and Figure 3 (p. 15). The additional explanation under Change 3 above interprets this rule in the response.

Comment 4:

The execution order, termination conditions, and time complexity of the algorithms are insufficiently specified.

In the description of the standard Louvain algorithm (p. 7, lines 238-242), the vertex traversal order and the selection rule when several moves yield the same modularity gain remain unspecified. For Algorithm 1, the authors state that when several shards have the same minimum load, one of them is selected deterministically (p. 8, line 278), but the selection rule itself is not given. Algorithm 2 uses the underspecified command 'Select one such account', and the rule for choosing among several destinations with the same maximum gain is also absent (p. 10). Since greedy algorithms may produce different results depending on the order in which elements are processed, these details are important.

In Algorithm 2, after each accepted move of account v_i, all accounts adjacent to v_i in the transaction graph are marked again as requiring examination. However, the authors do not prove termination of this procedure or provide an upper bound on the number of repeated examinations or moves. In Equation (19), the complexity is expressed in terms of r_1 and r_2 - the numbers of edge-processing passes during Louvain and boundary rebalancing, respectively (p. 11, lines 342-362). These quantities depend on the graph structure and the sequence of accepted moves, but neither their upper bounds nor their experimental values are provided. Therefore, Equation (19) does not provide an upper bound on the running time as a function of graph size and, consequently, does not support a substantiated conclusion about the scalability of the method.

Response 4: Thank you for this detailed comment. We agree that the original description did not distinguish sufficiently between method-level rules, implementation-dependent execution order, termination safeguards, and asymptotic complexity. The revised Sections 4.2-4.5 and the added implementation-level profiling address the method, termination, and cost issues. We provide the additional explanation of processing order below.

For standard Louvain, we retain the standard algorithm without introducing a new traversal or tie-breaking rule as part of LB-Louvain. During local moving, only a movement with positive modularity gain is accepted, and the candidate with the largest positive gain is retained. In the controlled implementation used for the experiments, the overall partitioning path is deterministic for a fixed input and configuration. Equal-gain cases therefore follow the deterministic iteration and tie-resolution behavior of the evaluated implementation. We do not retroactively introduce a lexicographic account-ID or community-ID rule that was not used in the frozen implementation, and we do not claim that standard Louvain necessarily produces a unique community partition.

For Algorithm 1, communities are processed in nonincreasing weighted-activity order. After the initial placement, each remaining community is assigned to a shard satisfying the least-loaded criterion in Equation (13). When multiple shards satisfy the same minimum-load condition, the evaluated deterministic execution mode selects one according to its deterministic iteration/tie-resolution order. The revised manuscript now states explicitly that the resulting mapping may depend on community-processing order and tie resolution and that uniqueness of the mapping is not claimed.

For Algorithm 2, the evaluated partitioning path is deterministic for a fixed input and configuration. The pseudocode selects an account requiring examination and retains a destination only when its gain is strictly greater than the current best gain. Consequently, within a given candidate order, a later equal-gain destination does not replace the earlier selected destination. The manuscript does not provide a separate lexicographic account-ID or candidate-ID ordering specification. We therefore distinguish repeatability of the evaluated execution from a mathematically unique mapping, and provide this additional clarification here.

We also added an explicit finite termination safeguard for boundary refinement. The implementation organizes refinement into repeated passes and stops when a complete pass accepts no account movement. In addition, a maximum of 70 passes is imposed. Thus, the evaluated implementation always terminates no later than this finite pass cap, although the cap is an implementation safeguard rather than a proof that the unrestricted local-improvement procedure has a graph-independent convergence bound.

Finally, we revised the interpretation of Equation (19). The quantities r_1 and r_2 remain graph- and execution-dependent. Equation (19) is therefore retained only as a stage-wise implementation-oriented cost decomposition and is no longer presented as a strict real-time upper bound or an asymptotic scalability result. Rather than assigning unsupported constant values to r_1 and r_2, we added direct five-run profiling of the complete partitioning path. Across 50,000-300,000 replayed-transaction prefixes and 4-24 physical shards, mean partition time remains below 100 ms. With four shards fixed, mean partition time increases from 17.32 to 55.26 ms as the transaction prefix increases from 50,000 to 300,000; at 300,000 transactions, increasing the shard count from 4 to 24 increases mean partition time from 55.26 to 91.02 ms. These measurements characterize the tested implementation range and are not used to infer asymptotic scalability beyond it.

Together, the revised manuscript and the explanations above clarify the deterministic execution behavior and order dependence, identify the finite termination safeguard for boundary refinement, explain the graph-dependent iteration counts in Equation (19), and provide direct partition-runtime and allocation profiling over increasing workload sizes and shard counts.

Change 1. We revised Section 4.2 to clarify the standard Louvain local-moving and termination behavior. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We clarified the processing order and tie dependence of the load-aware community-to-shard assignment. Relevant revised manuscript text (linear notation) is as follows:

Let ell(C_r) denote the weighted activity of community C_r. It is calculated from the weighted degrees of its accounts. The communities are processed in nonincreasing activity order.

After the initial assignment, each remaining community is mapped to the currently least-loaded shard:

phi(C_(r)) in argmin_(s_k in S) L_hat_k, r > q.

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.

Change 3. Clarification of Algorithm 2. The following explains the deterministic execution described in Section 5.1 and the candidate-selection logic in Algorithm 2; it is an explanation in this response, not a quotation of an added manuscript paragraph:

In Algorithm 2, "Select one such account" is governed by the account-processing order of the evaluated deterministic implementation. The manuscript does not specify a separate lexicographic account-ID order. Within the candidate loop, the best destination is updated only when Delta L_(i,b) > bestGain. Therefore, a later destination with an equal gain does not replace the earlier selected destination. This explains tie retention within a given candidate order; it does not establish a unique mapping independent of processing order.

Change 4. We added an explicit termination rule and finite implementation safeguard for boundary refinement. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 5. We revised the complexity analysis to make the roles of r_1 and r_2, and the limitation of Equation (19), explicit. Relevant revised manuscript text (linear notation) is as follows:

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

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

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(r_2 * |E|). Therefore, the overall time complexity is

O(|T_H| + r_1 * |E| + R log R + RK + r_2 * |E|).

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(|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.

Change 6. To complement the stage-wise complexity expression with direct implementation-level evidence, we added five-run profiling of the complete partitioning path in Section 5.4. Relevant revised manuscript text (linear notation) is as follows:

Location in the revised manuscript: Section 4.2, p. 8, lines 267-291; Section 4.3, pp. 9-10, lines 298-323, and Algorithm 1 (p. 9); Algorithm 2, p. 11, especially its strict-gain update in pseudocode lines 14-16; Section 4.4, pp. 11-12, manuscript lines 383-395; Section 4.5, p. 12, lines 399-421; Section 5.1, p. 13, lines 452-467; Section 5.4, p. 17, lines 561-581, and Figure 5 (p. 18).

Comment 5:

The effect of the individual stages of LB-Louvain on the reported experimental results is not investigated.

All experimental results are reported for the complete three-stage algorithm. On p. 13, lines 402-404, the authors explicitly state that the observed improvements are not attributed to any individual stage. Therefore, it is impossible to determine the contribution of each stage to the improved results. This is important: if approximately the same results can be achieved without the second or third stage, the need for that stage remains unjustified.

Response 5: Thank you for this important comment. We fully agree that the contribution of the two LB-Louvain-specific stages cannot be established from measurements of the complete pipeline alone. We therefore added a controlled component-wise ablation that directly follows the three variants requested by the reviewer.

Specifically, M0 uses standard Louvain for logical-community extraction, followed by deterministic non-load-aware community-to-shard placement, with boundary-account refinement disabled. Because the number of logical communities produced by standard Louvain generally differs from the configured number of physical shards, a baseline community-to-shard placement step is necessary before Louvain can be evaluated as a physical account-placement baseline. M1 adds the proposed load-aware community-to-shard assignment to M0 while keeping boundary refinement disabled. M2 denotes the complete LB-Louvain pipeline, adding the proposed boundary-account refinement to M1.

All three variants are evaluated under the same 300,000-transaction replay workload, 1500 TXs/s injection rate, 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, and the reported figures include 95% confidence intervals.

The results clearly distinguish the effects of the two proposed 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 indicates that Stage 2 primarily improves load distribution, with a small observed locality cost. Relative to M1, M2 reduces the cross-shard transaction ratio by approximately 0.92%, while the peak queue standard deviation changes by only approximately 0.46% and active throughput by approximately 0.42%. Stage 3 therefore primarily recovers transaction locality while largely preserving the load-balance improvement obtained by Stage 2.

These results show that the two added stages do not have redundant effects. The load-aware community-assignment stage primarily improves coarse shard-load balance, whereas boundary-account refinement primarily restores locality after coarse placement. We have revised the manuscript accordingly and no longer attribute the observed performance of the complete pipeline to an indivisible three-stage method.

In summary, we added a controlled M0/M1/M2 component-wise ablation to isolate the effect of load-aware community assignment and boundary-account refinement under identical experimental conditions.

Change 1. We added the formal definitions of the three ablation variants in Section 5.2. Relevant revised manuscript text (linear notation) is as follows:

Change 2. We added Figure 3 to report the component-wise comparison of transaction locality, active throughput, confirmation latency, and shard-load dispersion.

Change 3. We added the following component-wise interpretation to quantify the distinct effect of each proposed stage:

Location in the revised manuscript: Section 5.1, p. 13, lines 452-467; Section 5.2, pp. 14-15, lines 487-512; Figure 3, p. 15.

Comment 6:

The experimental validation is insufficient to support the claimed advantages. Only Monoxide and CLPA are used as baselines for the experimental comparison with LB-Louvain. Monoxide does not use adaptive account placement based on the transaction graph, so a substantial advantage over it is expected. At the same time, the Related Work section discusses other methods, such as TxAllo, ShardCutter, and workload-constrained graph-partitioning approaches, but these methods are not included in the experimental comparison. Therefore, the empirical evidence is not sufficient to justify the claimed advantages of LB-Louvain.

Response 6: Thank you for this important comment. We agree that broader empirical comparisons with recent adaptive account-placement methods would strengthen the evaluation when compatible runnable implementations are available. We therefore audited the evaluated BlockEmulator codebase before extending the controlled experiments and distinguished between methods that can be executed fairly under the same workload/system configuration and methods that can currently only be compared at the mechanism level.

CLPA has a compatible runnable implementation in the evaluated BlockEmulator framework and was therefore added as the controlled graph-based baseline in the new five-run experiment. Monoxide is retained only as archived evidence, because those measurements were produced on the earlier Ubuntu-based testbed and are therefore not pooled with the new controlled Windows experiments. We do not present Monoxide as a controlled same-testbed baseline for the revision experiments.

For TxAllo, ShardCutter, and workload-constrained graph-partitioning alternatives, compatible runnable implementations were not available in the evaluated codebase. We did not reimplement these methods solely for this revision, because an ad hoc reimplementation would require additional algorithmic and system-integration choices and could easily create an apparent numerical comparison that is not methodologically equivalent. Instead, we strengthened the Related Work section to compare these methods with LB-Louvain at the mechanism level and explicitly limited the scope of the controlled numerical comparison in the experimental setup.

Accordingly, the revised manuscript limits its controlled numerical comparison to CLPA and keeps Monoxide only in the separately labeled archived evidence. We therefore do not claim comprehensive empirical superiority over TxAllo, ShardCutter, workload-constrained graph partitioning, or all adaptive account-placement methods. The revised contribution claim is bounded to the compatible controlled comparison and the clarified mechanism-level positioning.

In summary, we clarified the compatibility scope of the controlled numerical baselines, added CLPA as the compatible controlled graph-based baseline, and strengthened the mechanism-level comparison with TxAllo, ShardCutter, and workload-constrained graph-partitioning methods.

Change 1. We strengthened Section 2 to compare LB-Louvain directly with CLPA, TxAllo, workload-constrained graph partitioning, and ShardCutter at the mechanism level. The corresponding revised Related Work text is described in text in our response to Comment 1 and is therefore not repeated here.

Change 3. We further clarified that the archived experiments and the new controlled revision experiments are separate evidence sets. Relevant revised manuscript text (linear notation) is as follows:

Location in the revised manuscript: Section 2, pp. 3-4, lines 113-139; Section 5.1, pp. 13-14, lines 468-483; Section 5.2, pp. 14-15, and Figure 3 (p. 15); Sections 5.5-5.6 and archived Figure 6 (p. 19).

Comment 7:

The description of the experiments is insufficient to reproduce the results.

Furthermore, the exact portion of XBlock-ETH, the dates or block numbers, the number of unique accounts and graph edges, the transaction-preprocessing rules, and the Louvain implementation parameters are not specified. It is also not stated which particular combination of transaction arrival rate and shard count produced the results shown in Figure 3. The authors explicitly state that the implementation code is not publicly available, and no supplementary materials containing the code are provided. Under these conditions, the results are practically impossible to reproduce independently.

Response 7: Thank you for this important comment. We agree that the original experimental description did not provide enough information for an independent reader to reconstruct the evaluated configuration. We therefore substantially expanded Section 5.1 and Table 1 to report the controlled testbed, exact workload file, available provenance, graph statistics, transaction aggregation rule, controlled parameter settings, experimental variants, and repetition policy.

For the dataset, the controlled experiments use the exact selectedTxs_300K.csv file distributed with the open-source BlockEmulator project. The file contains 300,000 selected historical Ethereum transactions and is identified in the revised manuscript by its SHA-256 checksum. BlockEmulator identifies the workload as being derived from XBlock-ETH; however, the upstream project does not provide the original selection procedure, Ethereum block-number range, or date range for this prepackaged file. We therefore report the exact distributed file and checksum rather than inventing unavailable provenance information.

We also report the resulting graph characteristics explicitly. For the full 300,000-transaction controlled workload, the graph contains 54,403 unique accounts and 64,378 undirected weighted account-pair edges, and standard Louvain produces 2,968 logical communities under the deterministic controlled configuration. Repeated transfers between the same unordered account pair are aggregated into the corresponding weighted edge.

The revised manuscript additionally specifies the complete controlled configuration used for Figure 3: 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 controlled testbed uses Windows 11, Go 1.19.13, an Intel Core i9-14900HX processor, and 31.73 GB of memory. Each formal controlled configuration is independently executed five times under identical settings, with the mean, sample standard deviation, and 95% confidence interval reported.

For Louvain, the method section now specifies the standard modularity objective and the local-moving and community-aggregation behavior used in LB-Louvain. Standard Louvain is used without changing its modularity objective or local-moving rule, and the controlled partitioning path uses deterministic execution for a fixed input and configuration. We do not introduce an additional LB-Louvain-specific Louvain resolution objective or claim that the resulting community partition is unique.

Finally, we agree that public release of the modified LB-Louvain implementation would provide stronger independent reproducibility. The underlying BlockEmulator platform is publicly available, but the modified LB-Louvain implementation used for the present experiments is not publicly released. We therefore do not claim full code-level reproducibility. Instead, the revised manuscript explicitly reports the workload checksum, controlled configuration, algorithm variants, graph statistics, and repetition policy so that the evaluated setup is documented as precisely as the currently available artifacts allow. The manuscript states this limitation directly.

In summary, we expanded the experimental description to report the exact controlled workload and checksum, available provenance, graph statistics, transaction aggregation rule, complete testbed and system configuration, partitioning variants, repetition policy, and the current code-availability limitation.

Change 1. We expanded Section 5.1 to identify the exact controlled workload, report the available provenance, and provide the resulting graph statistics. Relevant revised manuscript text (linear notation) is as follows:

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).

Change 2. We revised Section 5.1 to report the controlled hardware/software environment and the default configuration used by the reviewer-driven experiments. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 3. We added Table 1 to summarize the default controlled configuration and all reviewer-driven parameter variations.

Table 1. Controlled revision configuration and reviewer-driven experiment variations (text form).

Platform: BlockEmulator [25]; fixed.

Dataset: selectedTxs_300K.csv; fixed base workload.

Number of transactions: 300,000 by default; 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 by default; Table 1 lists 4, 8, 12, 16, 20, and 24 for the scalability experiment.

PBFT nodes per shard: 4; fixed.

Repartitioning interval: 50 s by default; 25, 50, and 100 s in the adaptation/cadence experiments.

Block interval: 5 s; fixed.

Block capacity: 2000 transactions; fixed, with byte-based block sizing disabled.

PBFT timeout: 20,000 ms; fixed.

Transaction batch size: 16,000; fixed.

Cross-shard load coefficient beta: 2.0 by default; 1.0, 1.5, 2.0, 3.0, and 4.0 in the sensitivity experiment.

Partitioning variant: M2 (complete LB-Louvain) by default; M0, M1, and M2 in the component ablation.

Configured Bandwidth parameter: 10,000,000; fixed. This is a configuration value, not an independently measured network throughput.

Operating system: Windows 11; fixed.

Implementation: Go 1.19.13; fixed.

CPU: Intel Core i9-14900HX, 24 cores and 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 standard deviation, and 95% confidence interval; no statistical-significance test is claimed.

Change 4. We clarified the repetition policy and the meaning of deterministic execution in the controlled experiments. Relevant revised manuscript text (linear notation) is as follows:

Change 5. We also specified the controlled partitioning variants, default load coefficient, and boundary-refinement stopping condition. Relevant revised manuscript text (linear notation) is as follows:

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 passes 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.

Change 6. We explicitly clarified the current code-availability limitation rather than implying full public reproducibility. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 7. We revised the Data Availability Statement to identify the exact public workload used in the controlled evaluation. Relevant revised manuscript text (linear notation) is as follows:

Location in the revised manuscript: Section 3.2, pp. 5-6, Equation (3); Section 4.2, p. 8, lines 267-291; Section 5.1, pp. 12-14, lines 428-485; Table 1, p. 14; Section 5.2, pp. 14-15, and Figure 3 (p. 15); Data Availability Statement, p. 23, lines 748-751.

Comment 8:

The practical applicability of the method has not been demonstrated.

In the experimental configuration, repartitioning is triggered every 50 seconds (pp. 11-12). However, the authors do not report the time required to construct the graph, run Louvain, assign the communities, and perform boundary rebalancing. Moreover, Algorithms 1 and 2 only construct the target mapping and do not transfer account states (p. 10, lines 340-341), while the time required by the Transaction-Aware Activation procedure to actually migrate account states to their newly assigned shards is not reported. It is therefore unclear whether the entire repartitioning cycle, including state migration, can be completed within 50 seconds, especially for graphs containing millions of accounts and transactions.

Response 8: Thank you for this important comment. We agree that the practical feasibility of periodic repartitioning cannot be established from the partition-quality metrics alone. We therefore added separate measurements for partition computation and complete mapping activation/state migration, because these are distinct parts of the reconfiguration cycle.

First, Section 5.4 now profiles the complete account-partitioning path over replayed-transaction prefixes from 50,000 to 300,000 and physical-shard counts from 4 to 24. The measured quantity is the total partition-computation time for the evaluated implementation rather than only the asymptotic expression in Equation (19). With four physical shards fixed, the mean partition time increases from 17.32 ms at 50,000 transactions to 55.26 ms at 300,000 transactions. At 300,000 transactions, increasing the physical-shard count from 4 to 24 increases the mean partition time from 55.26 to 91.02 ms. Across all evaluated combinations, the observed partition computation remains below 100 ms.

Second, we added the controlled Transaction-Aware Activation and migration experiment in Section 5.7. This experiment applies the target mapping produced by the complete LB-Louvain pipeline and measures migrated accounts, application-level state-transfer volume, mapping/state-installation time, deferred transactions, end-to-end throughput and confirmation latency, and complete reconfiguration time. The mean total reconfiguration times are 8445.35 ms for Fine-Grained activation (FG), 8615.91 ms for Full Locking (FL), and 7895.27 ms for Stop-the-World activation (STW), corresponding to approximately 7.90-8.62 s. All three measured modes therefore complete well within the configured 50-s repartitioning interval under the evaluated 300,000-transaction workload.

We also distinguish the interpretation of the individual measurements. The approximately 230-306 ms mapping-and-state-installation measurements in Figure 7(d) are not treated as the complete migration duration; they terminate before the subsequent release and rerouting of deferred transactions. The complete reconfiguration-time measurements in Table 2 include the broader reconfiguration path and are therefore the quantities used when comparing against the 50-s interval.

Finally, we have deliberately limited the practical claim. The present measurements show that the complete measured reconfiguration fits within one 50-s cycle for the evaluated BlockEmulator workload and tested graph/shard ranges. They do not establish that the same bound will hold for million-account graphs, geographically distributed deployments, heterogeneous WAN conditions, or arbitrary failure scenarios. The Discussion now states these scope limitations explicitly and identifies broader distributed and workload evaluations as future work.

In summary, we added direct measurements of the complete partitioning path and the subsequent mapping-activation/state-migration path, compared the measured complete reconfiguration time with the configured 50-s repartitioning interval, and explicitly limited this feasibility claim to the evaluated workload and implementation range.

Change 1. We clarified in Section 4.4 that Algorithms 1 and 2 construct the target mapping only and do not themselves perform state transfer. Relevant revised manuscript text (linear notation) is as follows:

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.

Change 2. We added implementation-level profiling of the complete partitioning path in Section 5.4. Figure 5 is described in text in our response to Comment 4 and is therefore not repeated here. Relevant revised manuscript text (linear notation) is as follows:

Change 3. We added Section 5.7 to evaluate the application of the target mapping during actual state migration. Relevant revised manuscript text (linear notation) is as follows:

Change 4. We added Figure 7 to report transaction deferral, end-to-end throughput and confirmation latency, and mapping/state-installation time during mapping activation.

Change 5. We further connected mapping activation with end-to-end transaction execution. Relevant revised manuscript text (linear notation) is as follows:

Change 6. We added Table 2 to report migrated-account volume, state-transfer volume, mapping/state-installation time, and complete reconfiguration time.