0

We have developed a small program that uses the EOS blockchain and we are storing some of our data in an EOS smart contract. Together with a UUID we are storing the object status. Our goal is to have an immutable record of the UUID and the object status, so that a 3rd party can look up the UUID for verification.

Over the last months, we have created thousands of record entries and used up quite some RAM already. As of today around we used - 77.46 MB of RAM. With the growing adoption of our application, we will need to buy a lot more EOS and buy RAM in the future.

I have the following questions

  • How can I optimize my smart contract to use less RAM? One status update at the moment cost us 479 Bytes. We have 3 per UUID. So in total 1437 Bytes for a full lifecycle.
  • Can I "delete" old records that are not used, or false posted and free up the used RAM?
  • If the application is no longer developed and the project closed, can I remove the smart contract and reduce the amount of RAM and get the EOS back?

Do you have any other suggestions on how to optimize our RAM use for our EOS smart contract? I was looking on Reddit and elsewhere for answers, but there is not much discussion about RAM out here.

cheers

Improve this question
4
  • Can you provide the contract's source code and/or the contract's name and the chain it's deployed to so that we can take a look?
    – cmadh
    Commented Oct 9, 2020 at 12:46
  • The name of the eos account is "rapidtestreg" with the same smartcontract name.
    – EOSdev6416
    Commented Oct 9, 2020 at 13:05
  • any updates? This form seems dead with very few users.
    – EOSdev6416
    Commented Oct 12, 2020 at 14:35
  • See answer below. Feel free to ping me in private on telegram, username is cmadh.
    – cmadh
    Commented Oct 13, 2020 at 12:14

1 Answer 1

Reset to default
0

I'm not sure how I can help you best. It is difficult without knowing the contracts code.

In any case you can delete data/multinindex-rows with the multiindex-erase function.

But i see a problem in the design of the contract. A resource saving contract should always avoid saving strings, but from what I see, you are saving three, per row.

To save additional memory, you should not save the hashes as strings but as a checksum. That way they will only cost ~half of the memory. A SHA256 as string is 64 (+1 because of null-termination) byte in size (one byte per character), but a SHA256 as checksum256 will only consume 32 byte. The same applies to the UUID, which is usually a 128bit number (16 byte), which then typically is represented as a hex-string. Storing it as a string instead of a number consumes 36 (+1 because of null-termination) byte instead of 16 byte.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.