Scalability Analysis of personal_world.CreateWorld on AVL-backed State

TL;DR

• CreateWorld successfully executed up to million scale (N=1,000,000).
• Each call is relatively heavy (~18M → 21M gas, ~2.6M storage).
• The cost increase with respect to world count was relatively gradual.
• Precondition batch execution also completed without timeout or OOG.

Conclusion:
The cost growth with increasing world count did not exhibit sharp linear escalation, but rather a gradual trend.
However, since the base cost of CreateWorld is already non-trivial and all worlds accumulate in a global state, the absolute cost can become significant at very large scale.

In other words, while the system appears stable in the short term, it is more appropriate to interpret it as a structure where costs accumulate as the state grows.

The full dataset is available here:

• Raw Milestone Data
• Raw Measurement Data

Structure Overview

The state structure handled by CreateWorld can be described as follows:

• Outer: AVL(worldID -> value)
• Inner value: map[string]string

The execution flow can be understood as:

1. Generate a new worldID
2. Insert worldID -> world map into the AVL structure
3. Create and store the world state (map[string]string)
4. Update related indexes (e.g., name, slug)

Note: In this experiment, N represents the total number of worlds, not the size of a single map.

Experimental Setup

• Execution environment: custom-built gnodev
• Branch: dev/jae/gas-model-improvements
• Commit: 2d507b86935576c6eb5b06cae3b14861f0090c87

Results (Milestones)

Execution completed successfully even at million scale.

Key Observations

1. High per-call cost

• gas_avg: ~18M → ~21M
• storage_avg: ~2.64M → ~2.68M

CreateWorld can be considered a heavy write operation.

2. Gradual cost increase with scale

• gas_per_item: ~+79.6%
• storage_per_item: ~+4.46%
• elapsed_sec: ~1.48x

The increase in world count did not lead to immediate cost explosion.

3. Stable precondition execution

• No timeout
• No OOG

The overall lifecycle remained stable under current test conditions.

Precondition Batch Trend

Even with fixed batch size, cost increased gradually.

Estimated Store Operations per Call

Based on static analysis (not actual VM instrumentation)

• StoreGetObject: [hypothesis] 6..10
• StoreSetObject: [hypothesis] 6..12

This estimate does not represent simple read/write counts, but rather includes:

• AVL/B-tree traversal
• Index updates
• Dirty object propagation
• Serialization overhead

Rationale

CreateWorld involves:

• AVL lookup (worlds)
• Index lookup (nameIndex, slugIndex)
• Object creation
• AVL insertion
• Index updates
• Owner chain propagation

Each of these steps may trigger:

• Object loads (StoreGetObject)
• Object writes (StoreSetObject)

Variability

Actual counts may vary depending on:

• Cold vs warm access
• Index structure
• Dirty propagation depth
• Validation branches

Therefore, these numbers should be interpreted as approximate bounds for understanding access scale, not exact measurements.

Interpretation

The total cost is likely driven more by the structural complexity of the write path than by the raw number of store operations.

Scaling Interpretation

Although the observed increase appears gradual, this should not be interpreted as inherently low cost.
The behavior is consistent with AVL-based structures where growth appears smooth.

However, extrapolating the current trend:

• A 100x increase in state size would still result in significant absolute cost growth
• Global state accumulation leads to long-term cost buildup

Thus, this system does not collapse abruptly, but exhibits cumulative cost growth as scale increases.

Core-Level Implications

From the current observations:

• AVL depth itself does not appear to be the first-order bottleneck
• The system remains stable at million scale

From a Dapp perspective, the primary cost contributors are likely:

• Object creation and storage
• Serialization/deserialization
• Dirty propagation
• Index updates

This suggests that the bottleneck is more likely within the write path rather than the AVL structure itself.

Suggested Directions (Non-binding)

While the current system behaves stably, long-term scaling may benefit from structural considerations:

• State partitioning (e.g., realm or shard-based separation)
• Improved write locality
• Separation of index structures
• Lazy initialization or indirect storage patterns

These are not immediate requirements, but may be relevant when targeting very large-scale systems.

Final Conclusion

CreateWorld is a relatively heavy operation, but remains stable up to million scale under current conditions.

However:

• Absolute cost continues to grow with state size
• The system exhibits cumulative cost characteristics
• Long-term scaling may introduce increasing pressure on both storage and execution

Therefore, while the current design is sufficient in the short term, larger-scale systems may benefit from structural optimizations such as state distribution and simplified write paths.