#Contract Instance Data

29 messages · Page 1 of 1 (latest)

rugged thicket
#

It's been suggested many times that contracts could have some global state, or instance state, attached to the contract instance that is always available without extra footprints, and doesn't require rent bumping because it's just always there.

When discussing offline this morning everyone was in favor, does anyone have any final concerns with adding this?

rare dove
#

Seems pretty non-controversial. @rugged thicket can you file an issue on the env repo?

#

Any thoughts about naming? I think I like globals most

rugged thicket
#

I'm not strongly opposed to globals being the name, but it may be problematic, because globals are a concept in code, and these values will not be global for all contract instances that are using the same WASM.

#

We may one day support wasm globals, which would in fact be shared by all instances using the same wasm.

mossy latch
#

Updating SCContractExecutable sounds like the right way to do this.

rugged thicket
#

I think I'm missing some context. I was think adding contract instance data will mean adding a list of key-value pairs to ..., where those keys are ScVal and the values are ScVal.

#

Why is ContractExecutable involved?

#

Ok, I'm looking at the XDR, and 🤯 no idea how instances are represented it seems 😄

#

We have no first-class ledger entry for contract instances?

#

I got confused because when I read ScContractExecutable, I thought that was the actual executable, the WASM, and not the instance.

mossy latch
#

I think everyone (including me) has been using the term "instance", when in code we refer to it as "executable".

#

We have a first-class ledger entry for ContractCode, but not the executable.

rugged thicket
mossy latch
#

"Executable" was deliberately chosen, and there was a document around this, but I don't remember much. @royal bane what do you think about this rename (and do you have a link to that doc)?

rugged thicket
#

Interestingly the document has "Contract Instance" as the formal term 🤔. See https://docs.google.com/document/d/10O6cWjOGnvhH4YaVRlR0CvBygeMcbY5hdT0Tq_pzlSM/edit?disco=AAAAnGDDZ3k

Google Docs
Proposal: Soroban naming brainstorming

Problem Currently the naming of the Soroban entities/operations is not consistent across subsystems (e.g. ‘create/deploy/register’ for contract instantiation or ‘source/code/Wasm’ for contract implementation etc.). The goal of this doc is to come up with unified terminology to use across the stac...

royal bane
#

document had my initial suggestions

#

I like 'executable' term for, well, executable, i.e. wasm reference or token

#

so I'd say have SCContractInstance that has SCContractExecutable executable and SCMap storage

#

(you still need some term for 'executable', right?)

#

SAC would also benefit from using instance storage btw

rugged thicket
#

Got it. So what your distinguishing is we have no "contact instance" type at all, rather than a misnamed one, it's implied via a contract data.

royal bane
#

yeah, or I'd say rather we don't have an instance now at all, just some key where we expect to find executable

rugged thicket
#

We have ContractData -> Executable which implies an instance, but what we need is ContractData -> ContractInstance -> { Executable, Map }

#

It's remarkable how Contract Instance Data, will live inside Contract Data ♻️

real brook
#

that might be confusing to people looking for contract building blocks, they might think they can set those variables and use someone elses installation

#

but it's still a nice idea