Giters

RGB-WG / rgb-std

RGB standard libs for WASM & low-level integrations (no FS/networking)

Home Page:https://rgb.tech

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot load Stock information after bump dependencies

crisdut opened this issue · comments

commented

Hi @dr-orlovsky,

The latest version of the rgb-std (44ee998) cannot load stock.dat files generated by the previously version when use Stock::strict_deserialize_from_file method, causing this error:

Error: unsupported value `46` for union `TySemId` encountered during decode operation

After investigating, I noticed this error is caused by changes in RGB standard library and bump strict-types and strict_encoding dependencies.

Previous stock.dat file works with:

  • strict-types 1.2.0 (official release)
  • strict-encoding 2.2.1 (official release)
  • rgb-std 0.10.2 (official release)

Previous stock.dat file does not works with:

  • strict-types 1.3.0 (official release)
  • strict-encoding 2.3.0 (official release)
  • rgb-std 0.10.2 (44ee998)

In addition, I will open a discussion with some ideas on how to link the strict-type lib version with Stock/Inventory to avoid being unable to access previous information due to compatibility breaks.

I hope this helps.

commented

Yes, I did write that the bugfix we had to do to fix the old issue will break binary compatibility. The tool is not required since after debugging the binary encoding MUST not ever change in a backwards-incompatible way. Even if we will have the tool, the users will loose their state, thus such things as the tool is pointless

commented

I am talking about this: strict-types/strict-types#11
it was a result of the discovery you made in RGB-WG/rgb-schemata#4

commented

Yes, I did write that the bugfix we had to do to fix the old issue will break binary compatibility. The tool is not required since after debugging the binary encoding MUST not ever change in a backwards-incompatible way. Even if we will have the tool, the users will loose their state, thus such things as the tool is pointless

In this case, do the contracts need to be re-issued?

commented

Yes. If the users are already using tokens than they have to contract the contract issuer and re-issue them - or being subjected to a discovered vulnerability.

commented

I have been thinking about the best way to upgrade the existing asset set (of RGB contracts which were never transferred). I came to the conclusion that the best way is this:

  1. Run a server-side API which is built with pre-fixed RGB v0.10 version and takes contract genesis (not stock!) and converts it to JSON/YAML returning to the client
  2. The pre-fixed client must extract geneses from the stock and store them separately (this is quite simple, I can add that to the pre-fixed version)
  3. Update clients to the post-fixed RGB (with no pre-fix support). The first thing on the startup which the client will do is to connect the server, send geneses of the assets, and receive YAMLs back
  4. Next, the client must delete stock, create a new one and issue new assets with the received YAML files.

This is not a migration service, this is one-time ad-hoc solution. Once there will be transfers happening it will be useless and the only way forward would be to re-issue by the issuer

commented

I have been thinking about the best way to upgrade the existing asset set (of RGB contracts which were never transferred). I came to the conclusion that the best way is this:

  1. Run a server-side API which is built with pre-fixed RGB v0.10 version and takes contract genesis (not stock!) and converts it to JSON/YAML returning to the client
  2. The pre-fixed client must extract geneses from the stock and store them separately (this is quite simple, I can add that to the pre-fixed version)
  3. Update clients to the post-fixed RGB (with no pre-fix support). The first thing on the startup which the client will do is to connect the server, send geneses of the assets, and receive YAMLs back
  4. Next, the client must delete stock, create a new one and issue new assets with the received YAML files.

This is not a migration service, this is one-time ad-hoc solution. Once there will be transfers happening it will be useless and the only way forward would be to re-issue by the issuer

Hi @dr-orlovsky,

Yesterday I solved the problem with an approach similar to this one, we are finishing testing here. Apparently everything is working.

Thanks for advising me.

commented

"Testing here" - seems you have lost a link