Gas fees for gno.land versus transaction for calls to Render(path string)

[schollz]

When browsing gno.land realms, the realms are essentially calling the Render(path string) function based on a path in the browser, e.g.: https://test3.gno.land/r/demo/users calls this function.

The same thing can be done on the command line, but in this case it will require using Gas:

> gnokey maketx call --pkgpath "gno.land/r/demo/users" --func "Render" --args "" --gas-fee "1000000ugnot" --gas-wanted "8000000" --broadcast --chainid dev --remote localhost:26657  --insecure-password-stdin=true zzkey1   

Enter password.
(" * [administrator](/r/demo/users:administrator)\n * [anarcher](/r/demo/users:anarcher)\n * [ideamour](/r/demo/users:ideamour)\n * [manfred](/r/demo/users:manfred)\n * [piupiu](/r/demo/users:piupiu)\n * [zo_oma](/r/demo/users:zo_oma)\n" string)
OK!
GAS WANTED: 8000000
GAS USED:   227586

Is there a command-line way of calling the specific Render(path string) function without having to have a Gas fee? Otherwise it seems like it might be viable for someone to make gas-free API calls to gno.land and parse the returned HTML for the response. Or, in the future, is it that the gno.land browsing will require gas?

[thehowl]

The direct answer to the question is that there is a way to call Render without using gas (after all, gnoweb is in essence a frontend to the RPC API). The logic is in handleRealmRender, but in essence, we can do this:

$ gnokey query --data 'gno.land/r/gnoland/blog'$'\n' --remote test3.gno.land:36657 vm/qrender
height: 0
data: # Gnoland's Blog

## [▸ Announcing the Gno.land Funding and Grants Program](/r/gnoland/blog:p/funding-program)

## [▸ Gno.land Community Game of Realms AMA #1 - Recap](/r/gnoland/blog:p/gor-ama1)

## [▸ Game of Realms Is On: Win Rewards for Contributing to Gno.land](/r/gnoland/blog:p/gor-launch)

## [▸ All You Need to Know About Game of Realms: Phase One](/r/gnoland/blog:p/gor-phase1)

## [▸ Intro to Gnoland - The Smart Contract Platform to Improve Our Understanding of the World](/r/gnoland/blog:p/intro)

## [▸ The More You Gno: Gno.land Monthly Updates](/r/gnoland/blog:p/monthly-dev-1)

## [▸ The More You Gno: Gno.land Monthly Updates - 2](/r/gnoland/blog:p/monthly-dev-2)

## [▸ Gno.land Community Technical AMA #1 - Recap](/r/gnoland/blog:p/tech-ama1)


$ gnokey query --data 'gno.land/r/gnoland/blog'$'\n''p/funding-program' --remote test3.gno.land:36657 vm/qrender
height: 0
data: # [Gnoland's Blog](/r/gnoland/blog:) / p / Announcing the Gno.land Funding and Grants Program

If you’re interested in building in Gno.land and using the Gnolang (Gno) language [...]

One key difference (AFAIK, either current or desired) between Render and a tx call is that Render cannot modify state when called outside a transaction. So this makes the whole content of a realm's state read-only. And currently a call to Render still "uses" gas in terms of CPU cycles that need to be run on one node, which does open up a possibility for abuse if the Render function does more than a simple markdown rendering of content but requires instead complex computation. The same could be said about vm/qeval, which kind of allows to do the same thing.

Seeing as these are essentially public API calls, potentially exploitable, we'll probably need to figure out a good strategy before mainnet.

---

Related: #649

[schollz]

Thanks @thehowl, that is super helpful. I was thinking of prototyping a Gno-backed database, using the smart-contract to store data but utilizing the gas-free reads. The gas-free reading in that is really nice.

As a manner of exploits, it is less nice - one could make a realm that just causes CPU overruns and hits allocation limits:

package crash

func Render(p string) string {
	s := ""
	if p == "cpuoverrun" {
		for {
		}
	} else if p == "allocationlimit" {
		for {
			s += "z"
		}
	}
	return s
}

which is easily spammed from gno.land. The exploit itself is annoying, but, to me, the main issue it brings is the level of allocation limit and level CPU overrun and the tradeoff with normal code. Currently the Gno limits seem reasonable as protection, but I have run up against them already once or twice with normal code.

I don't know how it could be done, but I wish there was a way to have higher limits for "safe" code and tighter limits on "dubious"/"exploitive" code.

[thehowl]

I don't know how it could be done, but I wish there was a way to have higher limits for "safe" code and tighter limits on "dubious"/"exploitive" code.

Well, it's hard to do. Probably things which are "expensive" to generate (like bytebeat audio) should be generated by the author (or by a paying tx, anyway), and instead public RPC calls follow the normal path for web2 like I suggested on #649: rate limiting.

public operations which are not transactions should probably be either removed before mainnet or limited in some way for safety. (ie. rate-limit cycles/allocs per ip per hour, make them in general low-priority so that blockchain TXs are executed first).

[leohhhn]

Related: #1523

TL:DR any exported function will use gas if called with maketx call or maketx run. The way to avoid this is to use the gnokey query command. Upper limit on query computation is being discussed.