xmtp
Commit payloads risk exceeding blockchain capacity
Problem statement
An issue with commit sizes has been uncovered through use of the migrator in testnet-dev and recent performance tests. An example of this problem was submitted in #1115.
A commit payload typically includes:
Fixed per group
- Group name/description/other metadata: 0 to unlimited
- Group ID: 16 bytes
Per member costs
- GroupMembership struct: 40 bytes per member
- MutableMetadata admin list: 32 bytes per admin member
Per installation costs (max 10 per user)
- Key: 32 bytes
- Credential payload: 32 bytes (inbox_id)
With the above, a user can be estimated at:
- Non-admin user:
40 bytes + num_installations × 1600 bytes - Admin member:
70 bytes + num_installations × 1600 bytes
This results in a per-user footprint ranging from ~1.6 KiB to ~15.7 KiB.
With a maximum of 250 users per group, a fully loaded group can produce nearly 4 MB commit messages — an unviable payload size for a blockchain transaction.
Current status
Currently, the L3 implementation (Arbitrum Nitro) used by our testnet chain enforces a maximum transaction size of 128 KB, inherited from go-ethereum.
Ongoing efforts aim to:
- Raise the transaction max size to 200–300 KB.
- Raise the maximum gas per block and/or lower the time to block.
Both are subject to stability testing being currently performed.
Larger transaction sizes bring several caveats:
- Increased receipt waiting times, as seen in #1115, where the transaction only confirmed after a significant delay. This affects directly to how fast users perceive the groups creation and modifications. The payload in that case is a bit north of ~80KB.
- Reduced throughput (messages per second), since total block gas is capped and payload gas cost scales with size.
Solutions
- Multi-part commit messages in
libxmtp - Multi-part events and indexing
