[META] Gno Wishlist / Feature Request Dump #975

zivkovicmilos · 2023-07-14T10:01:30Z

Overview

The purpose of this document is to outline several improvement areas for Gno, mainly concerning blockchain node functionality. For lack of a better name, the document is titled as a Wishlist of things that developers and implementation teams would like to see added to Gno.land in the near future, by the core team or by the community.

In addition to outlining the feature / improvement requests, this document aims to provide visibility on how far the efforts have progressed, and who is currently handling them.

These items have been compiled from day-to-day work on Gno, talks with implementation partners and discussions with the general community. Please feel free to propose additions and changes to this document, or to volunteer in handling a specific item.

Please note that the items here are not as general purpose as some other Gno roadmap items (ex. IBC, Realm <-> Realm interactions), but instead zero in on specific feature requests that should be achievable short-term.

This issue is meant to also encompass the OnBloc team's Gno Core issue tracker:
gnoswap-labs#7

Event Indexing

Outline

As the number of users of Gno.land grows, there is a need for quickly fetching and looking up past object information, like blocks or transactions. Previously, there was the ability for the Gno node itself to index transactions over RPC (HTTP / WS), but this functionality has since been deprecated.

Based on discussions with @jaekwon on on Gno Event Store PR (indexing) and tm2-js-client issue, we've finalized the scope of work that needs to be done in order to provide users with indexing functionality. This scope of work consists of building out a separate tool that is capable of parsing event information from the TM2 node, and internally indexing the data so it can be provided to users. The functionality that this tool should have is not limited to:

import past transaction data
monitor new event data
provide an RPC endpoint (HTTP / WS) for querying indexed data
provide the ability to subscribe to specific event types

The idea is that users can run their own indexers, or use existing ones (ex. the indexer for the testnet...), depending on their use-case.

Additionally, this tool would provide a way for users to subscribe to different events, like block generation events, or specific transaction events (discussed by the OnBloc team here).

Progress

feat: add file-based transaction indexing #546 provides the required foundation for saving TM2 events, so that they can be parsed by 3rd party tools
The separate tool mentioned in the outline will be built out as soon as feat: add file-based transaction indexing #546 is merged

Assignees: @zivkovicmilos

Realm Event Subscriptions

Outline

As Gno revolves around Smart Contracts (Realms), there is a need for tapping into real-time Realm data off-chain. For example, a Realm could house the validator set (addresses / public keys) for the running chain.

In order for critical data to be housed on a Realm, it should be reachable from a 3rd party process that potentially lives off-chain. In our validator set example, there should be a listener that can subscribe to Realm state changes, and execute node-specific protocol logic accordingly.

Solidity in Ethereum has a similar concept in the form of Events. In Solidity, users can specify an event emit, which is reflected in the Transaction Receipt as part of the execution log. Based on this log, users can subscribe to ongoing Events and be alerted the moment they are committed to the running chain.

This functionality can possibly rely on event dumping outlined in Event Indexing.

Progress

Original issue opened up by @r3v4s on the topic of event emissions: emit & event built-in functions #575
PR out by @anarcher to provide a PoC for the event emission issue: feat: event & emit in gno #853

Assignees: No one assigned :(

Gas Estimations

Outline

For users to send transactions that will eventually be committed to the Gno chain, they essentially need to provided 2 pieces of information gas-wise:

Gas Limit - the amount of gas (units of gas) the user is willing to pay for a given transaction to go through
Gas Price - the amount of native currency the user is willing to pay for a single unit of gas

Currently, gas estimation is not possible for a client application interacting with gno, and therefore applications and users need to guess the gas limit. If they guess incorrectly (too low), their transaction is rejected as being underpriced.

Additionally, there is the problem of gas fees being fixed to 1GNOT (1000000ugnot), as outlined in issue #649.

Ethereum has support for gas estimations with the following RPC endpoints:

eth_estimateGas - returns the lowest gas limit at which the transaction is successful. It finds the lowest value by doing a binary search over the gas range, and executing the transaction for each (middle) value in that range
eth_gasPrice - returns the current average gas price for a (any) transaction, in wei. Usually, this average is implemented as a rolling average value, and is tied temporally to the node serving the call (the average is reset when the node is restarted)

Progress

Original issue brought up by @zivkovicmilos: Package calls + deployments cost a fixed number of ugnot #649
On the same issue, @thehowl and @MichaelFrazzy have provided good feedback on potential pricing models
Gas Fee Equation issue, brought fourth by @MichaelFrazzy: Gno.land Fee Parameters #1106

Assignees: @MichaelFrazzy

ABI Support for Realms

Outline

Gno.land Realms expose public methods that can be queried off-chain by client applications. The problem lies in the fact that the responses of specific public methods can be different form primitive types in Golang, for example a struct or a type alias.

In this case, the response the clients will receive will contain the raw value and the type of response (ex my response MyComplexType), leaving the clients to do custom parsing on their own.

There is also the parallel problem of constructing method calls. Clients need to know upfront what kind of data needs to be packaged as the arguments of a public Realm method.

Ethereum Solidity Smart Contracts provide a contract ABI (essentially a JSON specification), which the clients can utilize to understand how to call Smart Contract methods, and what kinds of responses to expect.

Progress

Issue created by @moul on the topic: Support complex types when using clients #925

Assignees: No one assigned :(

Big.Int Support

Outline

Financial applications, especially exchanges, require a finer-grained control over big numbers in Gnolang. To this end, there is a growing need for representing these numbers in Realms and Packages. Additionally, many packages that could otherwise be ported to Gno are blocked by the lack of big.Int support.

Progress

PR opened by @r3v4s: feat: native bigint using math/big.Int #764
Closed PR by @r3v4s: feat: type conversion, opInc, opDec for bigint and bigdec type #676

Assignees: No one assigned :(

Improved Native Currency Faucet

Outline

Gno.land actually provides complete faucet support, in the form of a self-hosted faucet solution.

However, this faucet is quickly depleted on testnets such as test3, and leads to frustrations and bad UX for users trying to play around with Gno.land, as they need native currency to deploy their packages and interact with them.

In conversations with @Ticojohnny, we've determined that the best course of action is to have the following solutions in parallel:

faucet that is not quickly depleted for testnets
Discord bot that is capable of distributing funds to users

Progress

Original issue opened by @moul: Improving Faucet Solutions for Gno/Gnolang: Current and Long-Term Considerations #929
Discord community faucet bot, managed by @piux2: https://github.com/gnolang/community-faucet-bot

Assignees: No one assigned :(

Improved Gnolang Editor Plugins

Outline

Gnolang plugins are useful for interactive editors like VS Code and IntelliJ Goland, as they make the development workflow much smoother.

We have an unofficial Gno extension for VS Code, maintained by @harry-hov.
There is no plugin for IntelliJ, yet.

The biggest pain point of the plugin is that it doesn't provide intellisense inside the editor, which degrades UX.

Progress

VS Code plugin maintained by @harry-hov: https://github.com/harry-hov/vscode-gno

Assignees: @harry-hov for VS Code, No one assigned for IntelliJ :(

Improved Native Currency Handling in Gno

Outline

Gno.land Realms provide the ability to use the banker module to execute balance checks for addresses, and limited fund transfers.

However, the module does not support native currency transfers between user addresses on-chain (in a Realm method). This sort of functionality is paramount for financial applications, and it's an expected feature for many blockchains.

Progress

Issue opened by @r3v4s: feat(stdlibs/std)!: namespace minted coins with realm path #875

Assignees: No one assigned :(

Node Config Support

Outline

The TM2 node should be configurable through user input. Gno nodes do support user-defined configurations, through a concept called a configuration file.

Even though users can supply a configuration file as an input parameter for the gnoland command, the actual configuration file is never loaded and parsed.

This prevents things like setting custom listen addresses and ports, which are required for smoothly deploying Gno nodes to cloud services like AWS.

Progress

Closed PR by @albttx: feat(cli): add listen flag #729
CLI Refactor issue by @moul: CLI refactor #731

Assignees: No one assigned :(

Contract <-> Contract Interaction (same chain)

Outline

Contract <-> Contract interaction is a useful feature in many contexts. For example, a financial application (like an exchange) needs to know the token (represented as a Realm) balance of a specific address. These kinds of cross-realm state-reads unlock many possibilities for Gno ecosystem applications.

Progress

Issue opened by @moul that details different approaches META contract-contract interactions on a single chain #757

Assignees: No one assigned :(

Improved Repl

Outline

The Repl is being used on more use cases, like https://gno-by-example.com
Right now, its implementation is really simple and lacks some needed functionality, like supporting global vars, consts, interfaces, and structs.

Progress

Assignees: @ajnavarro

The text was updated successfully, but these errors were encountered:

MichaelFrazzy · 2023-07-14T13:28:02Z

Thanks for this, happy to circle back around to the gas equation! We can brainstorm everything needed to make sure it works with the endpoints and anything else required.

ajnavarro · 2023-07-21T10:04:19Z

Improved Repl

Outline

The Repl is being used on more use cases, like https://gno-by-example.com
Right now, its implementation is really simple and lacks some needed functionality, like supporting global vars, consts, interfaces, and structs.

Progress

Edit: Added to main issue.

thehowl · 2023-07-21T16:31:26Z

Thank you for this Milos. I've taken the liberty to update the title to be a [META] issue like Manfred often makes them; as I think it fits and makes them more searchable :)

@ajnavarro I think it makes more sense to put everything in the OP for the wishlist, so that we can just edit that as a team if there are any updates. You should have write access to the OP. Do you agree? 😃

ajnavarro · 2023-07-24T07:54:23Z

@thehowl Edited and added to the main issue.

r3v4s · 2023-07-27T07:35:44Z

I think #875 is related Improved Native Currency Handling in Gno, on terms of 'handling'

@r3v4s

# Description Succeed in my predecessor's legacy. I have implemented the output to show the path where the event occurred, as discussed in #1833. Also made it print the timestamp or block height together. ## Key Changes In this change, event emission functionality has been added to the Gno. The main changes include: 1. Introducing of the `emitEvent` function: - The `emitEvent` function emits an event based on the given type and attributes - Attributes are passed as an even-length of array key-value pairs - When emitting an event, the current _package path_, _timestamp_, and _block height_ information are recorded along with the event(discussed in #1833). This metadata provides additional context about where the event occured. 2. Additional of event-related types and functions in the `sdk` packages: - `NewEvent` creates a new `Event` object based on the provided information. - `ArributedEvent` struct contains informations such as event type, package path, block height, timestamp and attributes. But I'm not sure how to utilize the `eventType` yet. So, I've just put it as a placeholder which will be a disscussion for another time. - `EventArribute` represents an attribute of an event and consists of a key-value pair - `NewEventArribute` creates a new `EventAttribute` object based on the given key-value pair. ## Example ```go package ee import ( "std" ) const ( EventSender = "sender" EventReceiver = "receiver" ) func Sender(){ SubSender() SubReceiver() } func SubSender() { std.Emit( EventSender, "key1", "value1", "key2", "value2", "key3", "value3", ) } func SubReceiver() { std.Emit( EventReceiver, "bar", "baz", ) } func Receiver() { std.Emit( EventReceiver, "foo", "bar", ) } ``` ### Result ```json [ "{\"type\":\"sender\",\"pkg_path\":\"gno.land/r/demo/ee\",\"identifier\":\"SubSender\",\"timestamp\":1713846501,\"attributes\":[{\"key\":\"key1\",\"value\":\"value1\"},{\"key\":\"key2\",\"value\":\"value2\"},{\"key\":\"key3\",\"value\":\"value3\"}]}", "{\"type\":\"receiver\",\"pkg_path\":\"gno.land/r/demo/ee\",\"identifier\":\"SubReceiver\",\"timestamp\":1713846501,\"attributes\":[{\"key\":\"bar\",\"value\":\"baz\"}]}" ] ``` ## Related Issue/PR #575 emit & event built-in functions (@r3v4s) #853 feat: event & emit in gno (@anarcher) <- previous work. #975 [META] Gno Wishlist / Feature Request Dump (@zivkovicmilos) --------- Co-authored-by: n3wbie <r3v4@onbloc.xyz> Co-authored-by: Manfred Touron <94029+moul@users.noreply.github.com>

@r3v4s

) # Description Succeed in my predecessor's legacy. I have implemented the output to show the path where the event occurred, as discussed in gnolang#1833. Also made it print the timestamp or block height together. ## Key Changes In this change, event emission functionality has been added to the Gno. The main changes include: 1. Introducing of the `emitEvent` function: - The `emitEvent` function emits an event based on the given type and attributes - Attributes are passed as an even-length of array key-value pairs - When emitting an event, the current _package path_, _timestamp_, and _block height_ information are recorded along with the event(discussed in gnolang#1833). This metadata provides additional context about where the event occured. 2. Additional of event-related types and functions in the `sdk` packages: - `NewEvent` creates a new `Event` object based on the provided information. - `ArributedEvent` struct contains informations such as event type, package path, block height, timestamp and attributes. But I'm not sure how to utilize the `eventType` yet. So, I've just put it as a placeholder which will be a disscussion for another time. - `EventArribute` represents an attribute of an event and consists of a key-value pair - `NewEventArribute` creates a new `EventAttribute` object based on the given key-value pair. ## Example ```go package ee import ( "std" ) const ( EventSender = "sender" EventReceiver = "receiver" ) func Sender(){ SubSender() SubReceiver() } func SubSender() { std.Emit( EventSender, "key1", "value1", "key2", "value2", "key3", "value3", ) } func SubReceiver() { std.Emit( EventReceiver, "bar", "baz", ) } func Receiver() { std.Emit( EventReceiver, "foo", "bar", ) } ``` ### Result ```json [ "{\"type\":\"sender\",\"pkg_path\":\"gno.land/r/demo/ee\",\"identifier\":\"SubSender\",\"timestamp\":1713846501,\"attributes\":[{\"key\":\"key1\",\"value\":\"value1\"},{\"key\":\"key2\",\"value\":\"value2\"},{\"key\":\"key3\",\"value\":\"value3\"}]}", "{\"type\":\"receiver\",\"pkg_path\":\"gno.land/r/demo/ee\",\"identifier\":\"SubReceiver\",\"timestamp\":1713846501,\"attributes\":[{\"key\":\"bar\",\"value\":\"baz\"}]}" ] ``` ## Related Issue/PR gnolang#575 emit & event built-in functions (@r3v4s) gnolang#853 feat: event & emit in gno (@anarcher) <- previous work. gnolang#975 [META] Gno Wishlist / Feature Request Dump (@zivkovicmilos) --------- Co-authored-by: n3wbie <r3v4@onbloc.xyz> Co-authored-by: Manfred Touron <94029+moul@users.noreply.github.com>

zivkovicmilos added 🗺️good first issue🗺️ Ideal for newcomer contributors help wanted labels Jul 14, 2023

zivkovicmilos self-assigned this Jul 14, 2023

thehowl changed the title ~~[Feature Request Dump] Gno Wishlist~~ [META] [Feature Request Dump] Gno Wishlist Jul 21, 2023

thehowl changed the title ~~[META] [Feature Request Dump] Gno Wishlist~~ [META] Gno Wishlist / Feature Request Dump Jul 21, 2023

moul added this to 🚀 The Launch [DEPRECATED] Sep 5, 2023

moul moved this to 🌟 Wanted for Launch in 🚀 The Launch [DEPRECATED] Sep 5, 2023

zivkovicmilos mentioned this issue Sep 6, 2023

Should the response of an RPC realm function call have the return value? #1100

Closed

jefft0 mentioned this issue Sep 6, 2023

Berty's GnoMobile / Gno Native Kit Builder Journey gnolang/hackerspace#28

Open

moul added this to the 🌟 main.gno.land (wanted) milestone Sep 8, 2023

moul added this to 💪 Bounties & Worx Dec 22, 2023

moul moved this to Todo in 💪 Bounties & Worx Dec 22, 2023

notJoon mentioned this issue Feb 13, 2024

feat(gnovm, tm2): implement event emission with std.Emit #1653

Merged

dongwon8247 mentioned this issue Mar 25, 2024

Onbloc x Gno Core Workshop gnolang/hackerspace#61

Open

This was referenced Mar 25, 2024

[chain] Gas Estimations #1826

Open

[chain] Support for on-chain Realm Events #1833

Closed

[chain] ABI-like support for Realm / Package requests / responses #1842

Open

Kouteki added help wanted Want to contribute? We recommend these issues. and removed help wanted labels Oct 2, 2024

Kouteki modified the milestones: 🌟 main.gno.land (wanted), ⏭️Next after mainnet Oct 16, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[META] Gno Wishlist / Feature Request Dump #975

[META] Gno Wishlist / Feature Request Dump #975

zivkovicmilos commented Jul 14, 2023 •

edited

Loading

MichaelFrazzy commented Jul 14, 2023

ajnavarro commented Jul 21, 2023 •

edited

Loading

thehowl commented Jul 21, 2023

ajnavarro commented Jul 24, 2023

r3v4s commented Jul 27, 2023

[META] Gno Wishlist / Feature Request Dump #975

[META] Gno Wishlist / Feature Request Dump #975

Comments

zivkovicmilos commented Jul 14, 2023 • edited Loading

Overview

Event Indexing

Outline

Progress

Realm Event Subscriptions

Outline

Progress

Gas Estimations

Outline

Progress

ABI Support for Realms

Outline

Progress

Big.Int Support

Outline

Progress

Improved Native Currency Faucet

Outline

Progress

Improved Gnolang Editor Plugins

Outline

Progress

Improved Native Currency Handling in Gno

Outline

Progress

Node Config Support

Outline

Progress

Contract <-> Contract Interaction (same chain)

Outline

Progress

Improved Repl

Outline

Progress

MichaelFrazzy commented Jul 14, 2023

ajnavarro commented Jul 21, 2023 • edited Loading

Improved Repl

Outline

Progress

thehowl commented Jul 21, 2023

ajnavarro commented Jul 24, 2023

r3v4s commented Jul 27, 2023

zivkovicmilos commented Jul 14, 2023 •

edited

Loading

ajnavarro commented Jul 21, 2023 •

edited

Loading