-
Notifications
You must be signed in to change notification settings - Fork 39
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
Create two_phase_game_move_execution.md #2117
base: main
Are you sure you want to change the base?
Conversation
|
||
Ideally, the registration of the callback would be a "smart contract"-only action. | ||
Basically, the system contract that is called automatically will have a function where it allows anyone to register a callback. | ||
|
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.
We can add all this to the current contract, but it needs to be a different function with a different synthetic transaction that is potentially metered. Current callback passes all transactions for inspection which ruins privacy; We need a callback where we register data to callback and address, along with gas maybe?
So that for devs the experience can be
system.registerCallback(abi.encodeCall(thisContract.execute.selector, arg1, arg2));
2. During the "phase 1" transaction, the game dev will transfer some `value` from the caller to an address controlled by the sys contract. | ||
This address was allocated to this game during the callback registration (similar to how you have to reference a payment when you move money to some broker). | ||
Note: To the user, it will be equivalent to gas spent for the transaction. | ||
4. At the end of the batch, the sys contract will invoke the "phase 2" function of the game - one move at a time. |
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 think I'll say pretty much what's in the PR already, but just to be clear - system contract will invoke registered callbacks in order of registration; so we can think of it as a queue. registerCallback pushes in it, and then we pop. So if there is some ordering where contract A registers callback and then calls contract B in same transaction which registers another, then it comes back and third one is registered it should all be executed in order. Not sure if this will ever be of any practical use, but I think this is the intuitive expectation
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.
umm. We need to think about this a bit more.
Why this change is needed
Please provide a description and a link to the underlying ticket
What changes were made as part of this PR
Please provide a high level list of the changes made
PR checks pre-merging
Please indicate below by ticking the checkbox that you have read and performed the required
PR checks