Value with Callback (auto unlocks) #24
Conversation
evgenykuzyakov
requested review from
ilblackdragon,
SkidanovAlex and
MaksymZavershynskyi
|
I was thinking about security of this and it still seems ok.
|
Co-Authored-By: Maksym Zavershynskyi <35039879+nearmax@users.noreply.github.com> Co-Authored-By: Alexey <alexey@fckt.dev>
Co-Authored-By: Alexey <alexey@fckt.dev>
|
Please take a look again. Added diagram, receipts and separated scenarios for better explanation. |
evgenykuzyakov
requested review from
MaksymZavershynskyi,
lexfrl and
ilblackdragon
|
|
||
| Let's look at receipts (See [How runtime works](#how-runtime-work)): | ||
|
|
||
| ```rust |
There was a problem hiding this comment.
The transition to specific receipts is unclear. This pseudocode here demonstrates how receipts are created and updated during the execution of exchange method on dex. I think this should be stated more explicitly.
| predecessor_id: "dex", | ||
| input_data_ids: [], | ||
| output_data_receivers: [], | ||
| actions: [FunctionCall { method_name: "trasnferFrom", ... }], |
There was a problem hiding this comment.
We need an explanation on how locks are passed to the function calls, i.e. specify the args.
There was a problem hiding this comment.
Added args where it makes sense
| predecessor_id: "dex", | ||
| input_data_ids: ["data-id-1", "data-id-2"], | ||
| // 2 new data receivers we added for the received input data | ||
| output_data_receivers: [ |
There was a problem hiding this comment.
This is confusing. It says we don't actually add them to output_data_receivers, but just account for them. Maybe comment out this field here to empathize that it is not actually added.
There was a problem hiding this comment.
We need a different name for it.
There was a problem hiding this comment.
What I meant, it the receipt would look like this if we append new output data receivers to the exiting output data receivers.
|
|
||
| /// `dex` returns this callback (A7) using `return_promise`. | ||
| // This modifies A7, by redirecting output from A4. | ||
| ActionReceipt { |
There was a problem hiding this comment.
So this functionality is already implemented in the current runtime, when we use return_promise, correct?
| id: "D5", | ||
| receiver_id: "fun", | ||
| predecessor_id: "dex", | ||
| data_id: "data-id-3", |
There was a problem hiding this comment.
Generating this receipt requires modification to the runtime, correct?
There was a problem hiding this comment.
No. It's how it works. We always generate a data receipt.
| } | ||
|
|
||
| /// `dex` returns this callback using `return_promise`. | ||
| // No receipts are modified, but execution outcome for A1 changes to reflect to wait for A4. |
There was a problem hiding this comment.
but execution outcome for A1 changes
where I can see it?
There was a problem hiding this comment.
It's part of status in ExecutionOutcome in Runtime: https://github.com/nearprotocol/nearcore/blob/d869465f0400678b5df9e29d3bd926e8887d2337/runtime/runtime/src/lib.rs#L728
|
Going to write a new NEP (in short form first). Keeping this for eduction. Spoiler: We'll use Safes which is similar to move operator |
|
WIP for the next version: #26 |
No description provided.