Store bytecode in the datastore

[Eitu33]

Context

Smart Contracts bytecode are currently stored in a different way than the datastore entries, It would make sense to handle them the same way.

TODO

• [ ] Define if bytecodes should have a reserved datastore entry
• [ ] Store bytecodes as datastore entries
• [ ] Update bytecode handling to use the datastore

[damip]

I have a concern about this: imagine Alice creates a domain name resolution smart contract, and I decide to register an entry that contains bytecode, then I can just run a CallSC on that entry for my bytecode to be executed with the access rights of the DNS smart contract (code injection attack).

Clean solution: add an "executable permission bit" like in unix.

General solution: Add a "permissions" byte in each datastore value with the following bits:

• bit0 = mutability (1 = mutable, 0 = immutable)
• bit1 = executability (1 = executable bytecode, 0 = non-executable bytes)
• bits 2-7 = reserved for future use

[gregLibert]

I have a concern about this: imagine Alice creates a domain name resolution smart contract, and I decide to register an entry that contains bytecode, then I can just run a CallSC on that entry for my bytecode to be executed with the access rights of the DNS smart contract (code injection attack).

Address resolution service is not yet described, but I think that it will return an address, loading and its content will be done in the caller context, won't it ?

[damip]

I have a concern about this: imagine Alice creates a domain name resolution smart contract, and I decide to register an entry that contains bytecode, then I can just run a CallSC on that entry for my bytecode to be executed with the access rights of the DNS smart contract (code injection attack).

Address resolution service is not yet described, but I think that it will return an address, loading and its content will be done in the caller context, won't it ?

Address resolution will probably just be a smart contract, not something hardcoded

[AurelienFT]

General solution: Add a "permissions" byte in each datastore value with the following bits:

The bits are for me hard to understand and calculate for end user because they create datastore keys as string. IMO, I think having a convention on where we can store bytecode is more appropriate

[Eitu33]

The bits are for me hard to understand and calculate for end user because they create datastore keys as string. IMO, I think having a convention on where we can store bytecode is more appropriate

But the bits are only used for the datastore entries handling, the end user wouldn't even know about their existence

[gregLibert]

But the bits are only used for the datastore entries handling, the end user wouldn't even know about their existence

I'm not sure about that : at the end of the day it's the smart contract owner that will set the permission. And as a smart contract user, not knowing how it will behave is not reassuring.

[gregLibert]

General solution: Add a "permissions" byte in each datastore value with the following bits:

The bits are for me hard to understand and calculate for end user because they create datastore keys as string. IMO, I think having a convention on where we can store bytecode is more appropriate

I feel the same : we need an RFC on this.

[AurelienFT]

But the bits are only used for the datastore entries handling, the end user wouldn't even know about their existence

The developers need to know on which entry they can store their bytecode no ? Maybe I miss something

[gregLibert]

The developers need to know on which entry they can store their bytecode no ? Maybe I miss something

This is something that could be defined by convention here: https://github.com/massalabs/massa/discussions/2668 I'm waiting for an answer from @damip and I will add a key. What about Smart Contract?

[Eitu33]

The developers need to know on which entry they can store their bytecode no ? Maybe I miss something

This can be handled in massa-std for users that want simple usage, giving a datastore default value on create_sc calls.

Also are you guys suggesting we should have a reserved key for SC's? Or something like a SC-specific datastore?

For the first one I don't believe that's what we want since it prevents having multiples bytecodes in the same datastore. For the second one it would just mean having a different key format under the hood which would not be very different from the initial proposition.

I'm not sure about that : at the end of the day it's the smart contract owner that will set the permission. And as a smart contract user, not knowing how it will behave is not reassuring.

Yeah but we won't be asking the user to set the bytes himself, more like a permission argument in the set_datastore_entry call. And not just for SC's, we are going to need permissions on classic datastore values eventually as well.

[damip]

We must make sure that keys and values are bytes (and stop using strings, which is an ongoing effort)

[gregLibert]

General solution: Add a "permissions" byte in each datastore value with the following bits:

• bit0 = mutability (1 = mutable, 0 = immutable)
• bit1 = executability (1 = executable bytecode, 0 = non-executable bytes)
• bits 2-7 = reserved for future use

What are the management rules ? Can immutable smart contracts be deleted ?

[Eitu33]

What are the management rules ? Can immutable smart contracts be deleted ?

Not as a datastore entry, but it would make sense that they can be deleted when the associated address is.

[Eitu33]

After speaking with @gregLibert, I believe that what he describes in https://github.com/massalabs/massa/discussions/2668 must be taken into consideration before we decide how we want to handle bytecode. It seems like there is doubt about what it is that we want to achieve with storage.

[damip]

We won't do this for now