Repository navigation
[Task] Compare cost of using map as default storage for rust contracts #605
Description
Background
During DevConnect Buenos Aires the people of Solidity discussed on the problem of contact migration
As it happens on NEAR, their contracts store data in a linearly serialized way, as we do with Borsh. This makes them run into the same "state is corrupted" error when they update the contract's state struct.
They are proposing a new EIP where they simply store the contract state as a map: variable_name -> value
Since on a map different variables are always in a different space, most of the corruption problems are easily avoidable
Would be useful for us to run some benchmarks, both in terms of NEAR locked and gas overhead to maybe propose a similar NEP
User Story
Acceptance Criteria
Resources & Additional Notes
No response
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
- Status
Activity
garikbesson commentedon Jan 27, 2026
I compared two NEAR contracts (both are basic auction contracts):
storage_write(b"highest_bid", &borsh::to_vec(&highest_bid).unwrap());Both are deployed with the same init arguments (end_time, auctioneer) and the same sequence of actions. The test then compares (custom vs. default):
So, basically, the difference is not so significant to say that storing data in the state by keys doesn't make sense. It requires more NEAR to store the same data and more gas to save it, but "most of the corruption state problems are easily avoidable".
The repo with tests.