-
Notifications
You must be signed in to change notification settings - Fork 79
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
core: contractCall from native contracts #1271
Conversation
9b78da3
to
1b84514
Compare
Codecov Report
@@ Coverage Diff @@
## master #1271 +/- ##
==========================================
- Coverage 67.51% 67.50% -0.02%
==========================================
Files 216 216
Lines 18368 18368
==========================================
- Hits 12401 12399 -2
- Misses 5300 5302 +2
Partials 667 667
Continue to review full report at Codecov.
|
This is native contract calling another native contract. Have you tried calling regular contracts from native contract? |
And it's spawning another VM, which doesn't seem to be correct. |
At the same time C# node mostly changes |
1b84514
to
abb8a5b
Compare
abb8a5b
to
db27ddc
Compare
Now we have VM into interop context, so we're able to call other contracts from native contracts, but it's strange a bit, because if VM fails during invoking inner |
Well, that's a feature. That's what would happen with regular contracts calling each other and native contracts shouldn't be that much different. |
@@ -317,7 +317,7 @@ func TestNativeContract_InvokeOtherContract(t *testing.T) { | |||
}) | |||
|
|||
t.Run("non-native contract", func(t *testing.T) { | |||
// put some other contract into chain | |||
// put some other contract into chain (this contract just pushes `5` on stack) |
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.
This belongs to some different commit.
@@ -35,7 +35,6 @@ type Context struct { | |||
Notifications []state.NotificationEvent | |||
Log *zap.Logger | |||
Invocations map[util.Uint160]int | |||
ScriptGetter vm.ScriptHashGetter |
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 probably no longer need vm.ScriptHashGetter
type either.
} | ||
_ = vm.Run() | ||
if vm.HasFailed() { | ||
return stackitem.NewBigInteger(big.NewInt(-2)) |
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.
It's a bit strange that we're returning something here, but I guess there are not that many options we have.
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.
It was a test method, so I just put something there. What should we do in this case?
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.
Well, the vm already has failed. We shouldn't touch it, but at the same time we have to return something for Func
, so it probably could be just about anything.
We have VM inside the context, so don't need ScriptHashGetter anymore.
db27ddc
to
c87e226
Compare
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 it's good enough for now, the API might be a bit lacking, but at least there are no blockers for any real native contract requiring this feature.
Closes #1200
I made an example of such call, but not sure if this testcase covers the problem. If so, than we are able to perform calls from native contracts and it might be necessary to implement a separate method for such calls.