3

I wonder if you also need to take contract instance RAM usage into account as a dApp developer on top of estimating the persistent storage RAM usage (since it will have to be temporarily stored in the BP's memory every time an action executes). And if so, do you also have to take into account multiple users instancing the contract at the same time in the same block?

P.S.: On the Dawn 4.0 that I'm running accounts seem to have infinite RAM, so I have no idea how it's going to work in a real environment where devs actually have to purchase RAM.

2

You only need to cover the RAM per account the contract is deployed on via the setcode action. Several users can use that contract without additional RAM usage however, if someone deploys the same contract to multiple accounts we don't de-duplicate them in RAM.

P.S.: On the Dawn 4.0 that I'm running accounts seem to have infinite RAM, so I have no idea how it's going to work in a real environment where devs actually have to purchase RAM.

Controlling resource limits is the domain of the system contract. Deploying eosio.bios as the system contract (or no contract) results in the infinite RAM you mention. However, if you deploy a proper system contract based on eosio.system then you would have resource limits managed/enforced by staking tokens.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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