System entry point

[ethanfrey]

Closes #693

[ethanfrey]

Okay, rebased after latest fix to the test contract.
This should be done now and is ready for review

[webmaster128]

Looks good.

I just wonder if there is a good verb isntead of "system". We use verbs for the other calls as well (migrate, query, init). But I don't have a great idea right now.

[webmaster128]

What about structuring this as an enum, such that this gets a verb like SystemMsg::StealFunds as well as extensibility.

[ethanfrey]

As an example sure.

I am happy to rename it, but it is designed to allow some priviledged "system" calls as opposed to external calls. Unless you have a better name, I would like to merge and then we can rename before the 0.14 release when we have a good name.

[webmaster128]

As an example sure.

Yeah, I think it is easier for readers to habve a one-case enum than trying to wrap their head around a struct/enum mix.

I am happy to rename it, but it is designed to allow some priviledged "system" calls as opposed to external calls. Unless you have a better name, I would like to merge and then we can rename before the 0.14 release when we have a good name.

Agreed, let's merge as it. Will think about it.

[maurolacy]

Sorry, I missed this. Some late comments.

Regarding naming:
Maybe indicating the priviledged nature of the call in the name would be a good idea. Priviledged sounds bad, but maybe Admin, Administer, or even Root are good alternatives to System.

System / Admin for the messages / enums, and administer / root as a function might work.

[ethanfrey]

So we can root the contracts? I like it 😄

[webmaster128]

oO bad things showing up in the dictionary.

But looking the root/admin direction, what about sudo. It is short, and a verb.

[maurolacy]

I like it. It means "superuser do", which gives us another option: superuser. But I think sudo is better, as it captures the action.

[ethanfrey]

Okay, just pushed a commit to address the SystemMsg enum.

[maurolacy]

This looks good to me, and I think something like this will be necessary / useful, but I worry a bit about how it wil be controlled / secured.

[maurolacy]

Whitelists, I guess, or something like the Admin module? Maybe you can comment a little about it.

[webmaster128]

This looks good to me, and I think something like this will be necessary / useful, but I worry a bit about how it wil be controlled / secured.

The handle entry point is only executed because the chain calls it when seeing a transaction with a MsgEcecuteContract. The migrate entry point is only executed because the chain calls it when seeing a transaction with a migrate message and checked the sender address is the admin address. And here, the system is only executed whenever the blockchain decides to. This may be a result of some transaction type, but it can also be based on other events like at the beginning of each block.

What all cases have in common is the contract is never executed by the end user directly. Only the functionality explicitly exposed to the user is available.

[maurolacy]

Thanks. So, system basically is an internal function, and not an entry point. Plus, it's not available to contracts / contract devs.

[webmaster128]

Not quite. All entry points are entry points to the contract, but not all of them are accessible to the user. The flow looks like this:

handle: User --> Transaction --> x/wasm --> wasmvm --> cosmwasm-vm --> contract

where x/wasm is the primary gate keeper. Now there can be other modules next to x/wasm requesting system calls:

handle: User --> Transaction --> x/wasm --> wasmvm --> cosmwasm-vm --> contract
                                   ^
                                   |
                                   |
system:                        x/whatever

[maurolacy]

Great diagram, thanks. When you write Transaction, it means a blockchain transaction, x/wasm <-> Cosmos SDK interaction, etc., etc.

What happens with the messages generated / returned by a contract, from this new system call, and from handle? What is the flow / what are the differences?