SC Datastore

[sydhds]

Intro

Currently our ledger is a key value map where the key is an address and the value holds a balance (in fact, 2 balances)
, a bytecode and a datastore. The datastore is also a key value map where the key is a byte array (with a max size of 255 byte)
and the value is a byte array (with a max size of 10Mb).

This RFC suggests to move the bytecode field directly into the datastore and adding some flags to mark entries as
executable (or not). A non-exhaustive list of benefits could be:

• Non-executable smart contract (for Layer 2 chain)
• Having code library for smart contracts (similar to DLL)
• Separate deployment code from smart contract code (no more hardcoding)

Modifications

In Ledger Datastore

The datastore would still be a key value map but the value would change from a byte array to:

• a flag (1 byte)
• a byte array

The flag will be used as a bitflag:

• bit 1 holds for executable / non-executable.
• Other bits are unused for now and left for future use.

In ExecuteSC / CallSC operation type

In current code, ExecuteSC has a bytecode parameter (as a byte array) among others. A new field 'datastore' (operation
datastore) would be added, allowing to pass additional data accessible from the Smart Contract (in bytecode).
This new field is a regular key, value map (key: byte array, value: byte array).

Note that the datastore limits are the same as the ledger datastore.

Smart Contract ABI addon

The following new functions would be useful for smart contracts:

• Related to operation datastore:

  • get_op_keys(): return a list of available keys in the datastore given to ExecuteSC
  • has_op_data(key): check if key is present in operation datastore
  • get_op_data(key): get the value associated with key

• Related to ledger datastore:

  • set_flag(flag, entry, value): allow to change the ledger datastore flag entry (e.g executable or not).
  • set_flag_for(addr, flag, entry, value): same as above but for the given address
  • get_flag(flag, entry): get ledger datastore flag entry
  • get_flag_for(addr, flag, entry): same as above but for the given address
  • get_keys(): return a list of available keys in the ledger datastore
  • get_keys_for(addr): return a list of available in the ledger datastore of given address

Smart Contract ABI modifications

In several spots, 'String' are used, thus requiring to use base64 to pass bytes:

• create_sc
• send_message
• call

The following functions will be removed:

• set_bytecode
• set_bytecode_for

As this can be replaced by set_data and set_data_for functions.

[sebastien-forestier]

Hello!
I don't understand why we need this executable flag, why layer 2 could not put code in the datastore anyway in the format they want ?
It looks like much added complexity and storage :)

[sebastien-forestier]

About putting the bytecode in the datastore, are we sure of the benefit vs the added user complexity of having forbidden keys ?

[damip]

@sebastien-forestier Thanks for the feedback !

Putting the bytecode in the datastore allows:

• storing/calling multiple programs per address (useful ?)
• much simpler, unified and maintainable code for:
  • bootstrap
  • ledger
  • state changes
  • speculative states
  • ABI / interface
  • storage costs

If we put bytecode in the datastore and we add a "key" parameter to the call ABI allowing to call any of the stored bytecodes on an address, there is a security risk: if you're not careful, users could add an entry with bytecode in your datastore, then call that bytecode in the context of your SC to steal its coins. WIth the executable bit we remove this risk.

Another bit of this flag byte could be used to mark the entry as "protected", and datastore access functions would have a parameter "allow_protected" set to false by default to prevent reading/writing protected entries of the datastore, like for example the stored website. That way, no need for reserved keys, and no risk of overwriting any of the protected entries.

Another bit of this flag byte can be used to mark specific datastore entries as immutable, which is useful for example for decentralized websites to have immutable JS but still be able to operate a database.

[qdrn]

If we put bytecode in the datastore and we add a "key" parameter to the call ABI allowing to call any of the stored bytecodes on an address, there is a security risk: if you're not careful, users could add an entry with bytecode in your datastore, then call that bytecode in the context of your SC to steal its coins. WIth the executable bit we remove this risk.

Users can still maliciously make you change the flag value, no ? How is that different than making you put malicious bytecode in your address datastore.

[damip]

In practice, you won't be using set_flag often in your smart contract, mainly only at initialization.
What the users can trigger is typically only set_data/get_data.

[sebastien-forestier]

* storing/calling multiple programs per address (useful ?)

Not sure, you can put several functions in your program anyway

[sebastien-forestier]

Another bit of this flag byte can be used to mark specific datastore entries as immutable, which is useful for example for decentralized websites to have immutable JS but still be able to operate a database.

In fact I'm wondering why/when it would be useful to have a mutable bytecode or a mutable website code.
Mutable code is not a "contract" anymore, not something that is agreed upon / signed / trusted.

So to me the most natural thing to do is to keep balance/bytecode/website/datastore, where only the datastore is mutable through code (or to put balance, bytecode and website in the datastore with reserved keys and immutability + particular rules for balance).

[damip]

Adding a "website" column to the core ledger, and hardcoding the concepts of "websites and bytecode are immutable, everything else is mutable" would be a strategic mistake for our architecture. It would:

• complicate the code (bootstrap etc...) significantly because there would be "if website, if bytecode etc... " exceptions everywhere
• prevent the core from being agnostic to what is stored (why do we need core to know about the concept of website ? what about other external higher level applications that require non-mutability ?)

[damip]

@gregLibert any opinions ?

[sebastien-forestier]

Setting smart contracts as possibly mutable is a huge change in dev/user experience w.r.t Ethereum, cf the litterature on this topic in Ethereum community:

• https://hackmd.io/@vbuterin/selfdestruct
• https://matt-rickard.com/smart-contract-immutability
• https://arxiv.org/abs/2206.00716
• https://tjayrush.medium.com/smart-contracts-are-immutable-thats-amazing-and-it-sucks-e0fbc7b0ec16
• https://medium.com/coinmonks/upgradeability-may-not-be-a-bug-96ff3cb6e41f

In the end it might be a user experience improvement, or it might not be, but for sure we have to thoroughly discuss the implications before implementing it.

[qdrn]

Once parallel and sequential balances are unified SC addresses and user addresses will behave differently so I don't think it's a big deal to not allow SCs on user addresses.

Anyway, you can already mutable SCs. It's just (maybe) harder.