VIP: Add keyword for immutable state variables

[buckle2000]

Simple Summary

Add a keyword for state variables of a contract that ensures immutability

Abstract & Motivation

Data marked with this keyword must be set in __init__

This keyword will make code more readable, thus making it more secure.

The keyword might be

• final
• immutable
• frozen
• ... or whatever

Specification

If the keyword is final, then it can be used like this:

# Auction params
# Beneficiary receives money from the highest bidder
beneficiary: public(final(address))
auctionStart: final(public(timestamp))
auctionEnd: public(final(timestamp))

Immutability is checked only in compile time

Backwards Compatibility

None

Copyright

Copyright and related rights waived via CC0

[fubuloubu]

I like this proposal. It works for the concept of deployment parameters that is a pretty common usecase (for things like the ticker symbol of a token, withdrawal period of Plasma, etc)

As noted, it's basically a hint for auditing and a compile-time check, so not hugely necessary.

Maybe we could allow final constants to not have to be set/accessed with the self.CONSTANT syntax so it fits in the same way as we use constants (only set at deployment instead of in code)

[jacqueswww]

Just a note: Marking something as final means it can only be set in __init__ which also means we need to warn that a variables is set to default/zero if not assigned in __init__ (the alternative to the __init__ limitation being a check for 1 assignment maximum).

[fubuloubu]

Should the compiler throw an Error if it's not set in __init__? I would argue that's unintended behavior and they should either set it or make it a constant.

[jacqueswww]

Yes, this would definitely have to be an error as it violates final.

[jacqueswww]

Approved 👍

[charles-cooper]

for gas savings, we can skip SLOADing immutable variables. in the constructor, we can set the values of the immutable variables in a data section of the runtime code and then at runtime use CODECOPY to load the values.

[spinoch]

I would have expected this functionality to be implemented as part of constant, that feels more intuitive imo

[fubuloubu]

I would have expected this functionality to be implemented as part of constant, that feels more intuitive imo

A constant gets injected directly into the bytecode during compilation. The suggestion here would be a state variable that can only be set once (during __init__, or potentially during an initialize method w.r.t. create_forwarder_to-style proxies).

It would still be a storage variable. Dynamically assembling the bytecode during deployments is a really difficult exercise, but could be done as an optimization to further reduce code size/gas cost.

[spinoch]

Right. Thanks for the low-level hints.

It would still be a storage variable. Dynamically assembling the bytecode during deployments is a really difficult exercise, but could be done as an optimization to further reduce code size/gas cost.

I was thinking that one could have some sort of templating similar to say docker-compose or shell scripts where the contracts would get information from an environment variables kind of setup e.g. the code would look like

BENEFICIARY: public(constant(address)) = $BENEFICIARY

and at compile time the value of $BENEFICIARY is read from the environment and replaces the variable name.

This way, it is still a constant at compile time and we have the gas optimizations as well as relatively clean code.
Of course, this would imply having some kind of wrapper at compile time which replaces the placeholder constants for the desired values. One can easily do this using shell tools, but I'm unsure if the cost of maintenance and complexity are worth it

[fubuloubu]

at compile time the value of $BENEFICIARY is read from the environment and replaces the variable name.

I had a similar idea too, I think it would be useful but IMO that's a new VIP.

In general, I want to support using Vyper as a templating tool too. For example, in yearn-vaults we have a field that's generated based on the git tag, but that requires a lot of management to use correctly. if it instead looked like:

VERSION = public(constant(String[20])) = {{ $VERSION }}
BENEFICIARY: public(constant(address)) = {{ $BENEFICIARY }}

that would be pretty cool

[charles-cooper]

It would still be a storage variable. Dynamically assembling the bytecode during deployments is a really difficult exercise, but could be done as an optimization to further reduce code size/gas cost.

note for those looking at this issue for implementation details: in the current implementation (v0.3.3), immutables are appended to the runtime code during deployment, there is no storage overhead.