Make Gnorkle Agents Gas-Less

[Villaquiranm]

Related issues and PRs

• META GitHub oracle & r/gh
• feat: Oracle packages and Github verification realm #1568 @deelawn

Motivation

In issue #1568, @deelawn implemented a Gno-based oracle and provided an example of how to use Gnorkle to link a Gno wallet address with a GitHub handle.

Upon reviewing the current process, we identified two key points:

• First, only whitelisted addresses can view pending verification requests. Every time the GitHub Agent retrieves active verification requests, it incurs gas fees.
• Second, after the agent verifies off-chain that the user owns the GitHub handle, it must pay additional gas fees to register the verification on the ghverify (Gnorkle instance).

The challenge with this approach is that Gnorkle bears the entire cost of the GitHub verification process. While this is feasible, we must ensure that the agent consistently has enough tokens to cover these expenses.

Proposition

Allow Gnorkle to execute messages from any sender, whether they are whitelisted or not, but only if the message is proven to be signed by a whitelisted address.

An GnoEvent should be published each time a user requests verification (this covers first point). This event can then be indexed by the off-chain agent, which will attempt to verify the ownership of the account. If ownership is confirmed, the agent will issue a payload to the user in the following format:

GNORKLE_FUNC,PUBLIC_KEY,RELAYED_PAYLOAD_SIGNATURE,RELAYED_PAYLOAD

GNORKLE_FUNC = 'relay' // always relay for relayed messages
PUBLIC_KEY ='gpub...'  // Get it from gnokey list

// identical to a non-relayed ingestion message
RELAYED_PAYLOAD='ingest,FEED_ID,OK' 
RELAYED_PAYLOAD_SIGNATURE=Sign(RELAYED_PAYLOAD, privKey)

Delivrables

• Implement the native function verifySignature, which will take the public key, message, and signature as input, and return a boolean to indicate whether the signature corresponds to the provided public key, along with the address associated with that public key. feat: verifySignature function #2776
• Emit an event each time a user invokes the GitHub verification method.
• Modify the Gnorkle code to handle relayed messages by adding support for message.FuncTypeRelay. Update the relevant section of the code, to include this new case and perform all necessary verifications.

[Villaquiranm]

@deelawn I would really appreciate your input here 💯

[deelawn]

Thanks @Villaquiranm; I'll take a look at this soon. @leohhhn because he said he'd be looking at gnorkle this week as well.

[leohhhn]

Taking a look; can you please name the issue more appropriately? It's not only about optimizing gas fees.

[Villaquiranm]

Taking a look; can you please name the issue more appropriately? It's not only about optimizing gas fees.

Thanks you're right maybe Enhance Gnorkle with Relayed Messages to Shift Gas Fees to Users for GitHub Verification would do ?

[n0izn0iz]

I propose: "Make Gnorkle Agents Gas-Less" although the initial title was already pretty accurate

• The event emission is about avoiding to pay gas for retrieving the requests list
• The off-chain signing and relaying by user is also about removing gas cost for the agent
• verifySignature is a dependency of relaying

[thehowl]

• Implement the native function verifySignature, which will take the public key, message, and signature as input, and return a boolean to indicate whether the signature corresponds to the provided public key, along with the address associated with that public key.

I'm not convinced by this approach.

I'd prefer if we changed std to have a method like GetMessage(), which returns a Gno representation of the corresponding std.Msg used to run the transaction, with maybe the following info for now:

type Message interface {
    Caller() Address
    Signers() []Address
}

(This could be an eventual substitute for GetOrigX functions; but I digress).

This way we can have gas-less gnorkle; by having the oracle multi-sig a message sent by the user. ghverify can "trust" the verification if the whitelisted address is in the signers, and by making sure std.AssertOriginCall (so that the verification function is not called indirectly).

[thehowl]

As for viewing verification requests, I agree it should be a gas-free query, but it should not work with events.

It should be a simple function, queryable using vm/qeval.

[n0izn0iz]

It should be a simple function, queryable using vm/qeval.

it could be also, but I think an event should be available too, so the nodes can push to the agents instead of the agents pulling repeatedly

[thehowl]

it could be also, but I think an event should be available too, so the nodes can push to the agents instead of the agents pulling repeatedly

If the problem we're trying to tackle is an off-chain oracle asking the chain "What users do I need to verify?", events do nothing to answer it; because they don't reflect what the chain has already stored. On the other hand, a queryable function does this.

I am starting to see that you and other contributors are beginning to use events for just about everything. I understand where you're coming from; working with the result of MsgCall is garbage for now, until we have #1776 and #1842. But understand that stuffing things into events to pass them off-chain is not good, as this is information that at least for now cannot be retrieved on-chain. We should look to make working off-chain just about as useful as working on-chain.

To me, in this specific case, there is no good reason to use events:

• They add no more useful information than what you can already fetch using the indexer
• They don't reflect the "current state" of all non-verified accounts; just the history of which verifications have been requested.
• They add data to the transaction result which is frankly not necessary.

so the nodes can push to the agents instead of the agents pulling repeatedly

Understand this is already possible and easy to do; you can use the websocket endpoint on the indexer and listen for events on the realm+function combination. Once you receive them, you can vm/qeval the node. Yes, it's an added step, but it also means that the oracle can work more statelessly, and use the chain as the source of truth rather than keeping an internal database of who's verified and who's not.