WIP: POC: std.Call to support dynamic import and call

[anarcher]

Description

This idea originated in #473 (comment) . This is not intended for general use, but may be useful in special situations (e.g. multi token management contract?).

import (
        "std"
)

func TotalSupply() uint64 {
        result := std.Call("gno.land/r/demo/foo20", "TotalSupply", nil)
        ts := result.Value[0].(uint64)
        return ts
}

func Faucet() {
        std.Call("gno.land/r/demo/foo20", "Faucet", nil)
}

It's POC. I'm not sure if this is the right way to go. and it needs more testing, there are still things to add (e.g. std.CallArgs).

// gno.land/r/test/stdcall/foo20
package main

import (
        "std"
)

func TotalSupply() uint64 {
        result := std.Call("gno.land/r/demo/foo20", "TotalSupply", nil)
        println("result:", result)
        ts := result.Value[0].(uint64)
        return ts
}

func Faucet() {
        result := std.Call("gno.land/r/demo/foo20", "Faucet", nil)
        println("result:", result)
}

func Render(p string) string {
        return "not implemented"
}

$ ~/bin/gnokey maketx call anarcher --pkgpath "gno.land/r/test/stdcall/foo20" --func "Faucet" --gas-fee 1000000ugnot --gas-wanted 2000000 --send "" --broadcast true --chainid "dev"   --remote "127.0.0.1:26657"
Enter password.

OK!
GAS WANTED: 2000000
GAS USED:   460042

$ ~/bin/gnokey maketx call anarcher --pkgpath "gno.land/r/test/stdcall/foo20" --func "TotalSupply" --gas-fee 1000000ugnot --gas-wanted 2000000 --send "" --broadcast true --chainid "dev"   --remote "127.0.0.1:26657"
Enter password.
(10160000000 uint64)
OK!
GAS WANTED: 2000000
GAS USED:   256703

How has this been tested?

It hasn't yet.

Please complete this section if you ran tests for this functionality, otherwise delete it

[piux2]

Description

This idea originated in #473 (comment) . This is not intended for general use, but may be useful in special situations (e.g. multi token management contract?).

What problem we try to solve with std.Call()?

We can just import gno.land/r/demo/foo20 and call TotalSupply() in our contract.

Dynamically package loading is not safe and trustable, and it could appear to call a contract that may not exist at the first place.

[anarcher]

It's POC. If no one needs this feature, or if there are security concerns, I'm fine with closing this PR.:-)

[r3v4s]

Description

This idea originated in #473 (comment) . This is not intended for general use, but may be useful in special situations (e.g. multi token management contract?).

What problem we try to solve with std.Call()?

We can just import gno.land/r/demo/foo20 and call TotalSupply() in our contract.

Dynamically package loading is not safe and trustable, and it could appear to call a contract that may not exist at the first place.

I think it's useful when we don't know exactly which package(realms) we need to import.
Perhaps this concept will be handy for dapps, for example, to import a list of pools in DEX.

And for the (security) concerns, maybe we can discuss & improve it 😄

[piux2]

Description

This idea originated in #473 (comment) . This is not intended for general use, but may be useful in special situations (e.g. multi token management contract?).

What problem we try to solve with std.Call()?
We can just import gno.land/r/demo/foo20 and call TotalSupply() in our contract.
Dynamically package loading is not safe and trustable, and it could appear to call a contract that may not exist at the first place.

I think it's useful when we don't know exactly which package(realms) we need to import. Perhaps this concept will be handy for dapps, for example, to import a list of pools in DEX.

And for the (security) concerns, maybe we can discuss & improve it 😄

@anarcher @r3v4s Those are very good thinking and use cases!

To include pool contracts in a dex, we can either use call back function through interface or pass by function to register the pool contract itself to the dex. We can achieve it using the idiomatic go style in gno. It avoids VM importing undetermined packages.

Solidity's low level call() is a EVM backdoor which should have been limited to minimum usage after they bootstrap the initial iterations of Solidity. It is not recommended to use in Solidity language specs either.

Since EVM and GVM are fundamentally different, we don't need to migrate things from Solidity. Many patterns in Solidity are work arounds to EVM's limitation in their evolving implementations. Those limitations may not exist in GNO VM.

The program written in idiomatic go/gno is a lot more readable, auditable and secure than Solidity.

[anarcher]

I'll close this PR. I think there's a better approach than this PR somewhere. :-)