Neo: Constant Storage for NeoContract

[erikzhang]

Abstract

The constant storage can be written once by the contract and can no longer be modified.

This is useful for storing data that should not be modified, such as total amount of tokens, digital identity information, and so on.

Specification

Design

1. Add constant flag to StorageItem. If a StorageItem has a constant flag with a value of true, then it cannot be modified or deleted. In the other word, it should cause the two APIs, Storage.Put and Storage.Delete, to fail. But it has no effect on Storage.Get.

2. For old contract data, their constant flag should be set to the default value false to keep backward compatibility.

3. To write a constant data, you need to call a new API: Storage.PutEx. It is similar to Storage.Put, but adds a parameter of type StorageFlags. If the parameter is set to StorageFlags.Constant, then the data written by it will be marked as constant. The readonly data can be read by Storage.Get.

4. Storage.PutEx costs the same as Storage.Put.

5. The data written by Storage.PutEx, whose key cannot be duplicated with other data, including those written by Storage.Put.

6. When Storage.PutEx is executed with StorageFlags.Constant, if it is found that writable data of the same key already exists, then this data will be marked as constant.

7. ~Each contract can only store up to 10KB of constant data. If this limit is exceeded, the constant writing operation will fail.~

8. When the contract is upgraded by the Contract.Migrate API, all the constant flags of the stored data will be set to false. This means that when the contract is upgraded, you will get an opportunity to modify the constant data.

New APIs

1. StorageFlags (enum)

   c# [Flags] enum StorageFlags : byte { None = 0, Constant = 0x01 }

2. Storage.PutEx (method)

   c# void PutEx(StorageContext context, byte[] key, byte[] value, StorageFlags flags)

Backwards Compatibility

For old contract data, their constant flag can be set to the default value false easily to keep backward compatibility.

[igormcoelho]

Fully agreed!

[igormcoelho]

How will it be implemented? GetReadonlyStorageContext?

[erikzhang]

Maybe System.Storage.PutReadonly.

[deanpress]

Will the storage items be separate from writable storage? So you can have a key abc in ReadOnly storage + separate abc in writable storage.

[shargon]

The read logic should be equal?

[erikzhang]

Will the storage items be separate from writable storage? So you can have a key abc in ReadOnly storage + separate abc in writable storage.

I don't think that read-only storage should be separated from read-write storage. A unified set of reading and writing methods should be provided.

[penlite]

I agree - all you need is some identifier that will cause Storage.Put and Storage.Delete to fail. Whether is separated as @deanpress says or not separated should be implementation detail but invisible at call level.

[erikzhang]

@igormcoelho @deanpress @shargon @penlite
I updated the specification of this proposal.

[shargon]

Very useful for totalSupply and other variables 👍

[igormcoelho]

This one is perfect Erik!! Ready to cook xD

[erikzhang]

I updated it again and changed PutReadOnly to PutEx. If everyone has no other opinions, I will start to implement it.

[igormcoelho]

Good, I like short names :)

[shargon]

PutConst maybe

[erikzhang]

This is not just about changing the name, it also adds a parameter flags to the method and extends the functionality in the future.

[igormcoelho]

Shargon, read the goddamn specification xD hahaha I didnt see that flag change too... ;) Erik, any "feelings" of possible extensions to the flags, or will just leave open to the future? I agree with the flags and name PutEx anyway.
EDIT: just had one idea hahaha flags will be nice ;)

[erikzhang]

Volatile?

[igormcoelho]

Exactly that! well done Erik :)

[shargon]

PutEx then :)