[Docs] Minting coins in Render()

[leohhhn]

Description

You can mint coins via the Banker in the Render function of a Realm (or package!) currently. This is an issue because the Render function is supposed to be called a lot, and by minting coins, we are changing the state (a costly operation). Render() should be read-only.

Deploy the following code under p/demo/mint:

package mint

import "std"

func Render(path string) string {
	coin := std.Coin{"mycoin", 100}

	this := std.GetOrigPkgAddr()
	me := std.GetOrigCaller()

	banker := std.GetBanker(std.BankerTypeRealmIssue)
	banker.IssueCoin(this, coin.Denom, coin.Amount)

	return banker.GetCoins(this).String()
}

The point of this issue is to discuss the distinction between functions that change the state, and functions that do not change the state at all - and their respective gas costs. As you might know, Ethereum's approach is to have normal, gas-costing functions, and view functions that just read the state of the contract.

In order to not diverge from standard Go keywords (ie adding keywords to differentiate these), would it be possible to have the first line of the function define what type of function it is, similar to how you can define a helper in Go tests with t.Helper()?

cc @moul @zivkovicmilos @MichaelFrazzy @thehowl

[deelawn]

Maybe we can disable calling Render as transaction and force everyone to use qrender as a query. Or reroute incoming tx requests to the query execution path when we are able to identify this is a call to Render, but I just took a look at that and it looks messy.

Follow up:
I've been thinking about other use cases of render and am not convinced that Render should not be allowed to change any state. The use case that first comes to mind is the following: There is a web app that pulls data from other sources (realms) and caches it within the local contract on an "as necessary" basis. Another use case is a counter that gets incremented each time the the Render function is invoked -- or any other types of analytics type operations.

So maybe the best solution here is no solution and the take away is don't put anything in your Render function that you wouldn't want someone to call or has potential to be abused in a way that might negatively affect the realm author.

[moul]

This issue extends beyond the current problem. The code can be executed on Render, which will cause further confusion.

var counter

func Render() string {
	counter++
	return fmt.Sprintf("%d", counter)
}

This will increment the counter before displaying, but the change will not be applied.

I believe the same applies to the banker (incrementation is done in memory but not applied on disk). If it's not the case, then we have a bug.

In my view, the issue is more about ambiguity than performance.

---

I suggest creating a gno lint formula that generates a warning message when Render modifies data.

I recommend checking out this realm that heavily utilizes Render modification: https://staging.gno.land/r/demo/tamagotchi.

[deelawn]

@moul I was just taking a closer look at this. Calling Render via maketx call will in fact change the state of the counter variable in the realm you posted. Calling render via gnoweb uses query vm/qrender under the hood to obtain a vm instance with non-persistent storage.

So do we need to make changes to prevent any Render invocations from changing state or should be make it abundantly clear in the docs that there is no guarantee Render won't change the state.

[deelawn]

Is there any action to take or can we close this?

[zivkovicmilos]

Solution proposed by @moul on our test4 alignment call:

• Possibly rename this to dry-run or something similar and / or
• Render stays as it currently is - it's fine to modify state, we just need to add a disclaimer in the documentation

[Kouteki]

Moving to Triage until we choose a solution

[Kouteki]

We're going with option 2: Render stays as it currently is. We just need to add a disclaimer in the documentation.