-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System entry point #793
System entry point #793
Conversation
ef979d0
to
09534be
Compare
Okay, rebased after latest fix to the test contract. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
pub struct SystemMsg { | ||
pub recipient: HumanAddr, | ||
pub amount: Vec<Coin>, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about structuring this as an enum, such that this gets a verb like SystemMsg::StealFunds
as well as extensibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we can root
the contracts? I like it 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oO bad things showing up in the dictionary.
But looking the root/admin direction, what about sudo
. It is short, and a verb.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it. It means "superuser do", which gives us another option: superuser
. But I think sudo
is better, as it captures the action.
Okay, just pushed a commit to address the SystemMsg enum. |
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. |
Whitelists, I guess, or something like the |
The 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. |
Thanks. So, |
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:
where x/wasm is the primary gate keeper. Now there can be other modules next to x/wasm requesting system calls:
|
Great diagram, thanks. When you write What happens with the messages generated / returned by a contract, from this new |
Closes #693