Expand BLOB in the netmap contract #298
Labels
enhancement
Improving existing functionality
I3
Minimal impact
netmap
Netmap contract related issue
S1
Highly significant
U4
Nothing urgent
Milestone
Comments
roman-khimov
added
enhancement
|
Oh, and maybe this would allow to solve node state synchronization issue (IIUC there is one state in the BLOB and there is another one in the |
|
Seems to be required for #297. |
roman-khimov
added a commit
that referenced
this issue
Nov 19, 2024
This format is added in parallel to existing one because we can't migrate in the contract easily, it'd require complete protobuf parser in VM. Instead we provide a secondary map here that works similar to the old one (except it doesn't have any listing or duplication issues). The expection is that nodes will send _both_ transactions starting from some time, we'll monitor them and transition to using new map only in subsequent IR/SN release. Then contract could be updated to drop the old data. Signed-off-by: Roman Khimov <[email protected]>
roman-khimov
added a commit
that referenced
this issue
Nov 19, 2024
This format is added in parallel to existing one because we can't migrate in the contract easily, it'd require complete protobuf parser in VM. Instead we provide a secondary map here that works similar to the old one (except it doesn't have any listing or duplication issues). The expection is that nodes will send _both_ transactions starting from some time, we'll monitor them and transition to using new map only in subsequent IR/SN release. Then contract could be updated to drop the old data. Signed-off-by: Roman Khimov <[email protected]>
roman-khimov
added a commit
that referenced
this issue
Nov 25, 2024
This format is added in parallel to existing one because we can't migrate in the contract easily, it'd require complete protobuf parser in VM. Instead we provide a secondary map here that works similar to the old one (except it doesn't have any listing or duplication issues). The expection is that nodes will send _both_ transactions starting from some time, we'll monitor them and transition to using new map only in subsequent IR/SN release. Then contract could be updated to drop the old data. Signed-off-by: Roman Khimov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On one hand, it designed to not care about node's data at all. On the other, it does
and a number of other similar things internally to get some data. Maybe having a structure defined in a contract would simplify things a bit (and some change to the storage scheme is needed anyway because of #297).
The text was updated successfully, but these errors were encountered: