[RFC] Discussion on the official Gno SDK (JS/TS + Gno)

[dongwon8247]

Description

I've opened this issue to openly discuss on the official Gno SDK (JS/TS + Gno), which @zivkovicmilos and the Onbloc team have been discussing. Dapp developers that want to build in Gno may encounter difficulties in implementing crypto middleware to interact with the Gnoland blockchain. This can be a significant hurdle for developers, and not good for the ecosystem from a maintenance and security standpoint of view. There should be an official way of interacting with Gno using official libraries for dapp developers, and I hope this discussion with Milos and the Onbloc team helps with that.

*I've also added thoughts about some painpoints and feature suggestions we've encountered while developing Adena for Gno.

Experience

1. Painpoints when developing Adena for Gno

• Dependency for cosmjs - we've developed the Adena-module
• Lack of documentation for functions - as of now, devs need to read the codes line by line to understand each function (but we now have this doc)
• Absence of key functions for dapp development such as the txindexer or subscribe
• Absence of a gas tracker which forces us to put max amount for gas wanted

2. What features are needed the most

• A search feature for the max gas fee or gas estimation when running vm.m_call
• Improvements to account balances when querying bank/balances
  • A way to identify tokens such as a path or a contract address is needed
  • The response structure should be changed
• Transaction indexing (Tx indexer)
  • Options for searching (ex: by address, order by ascending/descending)
• A way to check Tx Commit Status
  • To NOT use broadcast_tx_commit, looking up a commit status with a hash that is returned as the response for broadcast_tx_sync should be enabled
• Read-only ABCI query
  • vm/qrender and vm/qeval are not optimized for data handling
  • We'd like to see these changed to where it's easier to use the returned data

3. RPC routes we'd like to see added / changed

• Customizable network configurations (for IBC)
• Websocket or gRPC implementation to stabalize the comms with Tendermint RPC

4. What Adena handles locally, but could work out of the box with an SDK

• What Adena handles locally: secp256k1, private keys, tx signing, account addresses, ledger, etc. (Source Link)
• What can be replaced with the SDK: secp256k1, private keys, tx signing, account addresses, ledger, username <> address resolving, etc.
• SDK Customizing: Ledger, Prefix supported addresses to prepare for IBC

Suggestions

Most commonly used functions

• abci_query
  • auth/accounts
  • bank/balances
  • vm/m_call (used together with broadcast_tx_sync)
  • vm/qeval
• broadcast_tx_sync

Functions we'd like to see on GnoSDK

• Account Generation
  • Mnemonic
    • Secp256k1 + HD Path
  • Private Key
  • Ledger (private key-less)
    • Ledger HQ + HD Path
• Accounts
  • Address by prefix (bech32 + prefix)
• Transactions
  • Messages
  • Signing
  • Signing on Ledger
  • Transfers
• RPC Comms + abci query
  • Network configs
  • Account search
  • Balance search (with token types)
  • Network fees & gas price search - estimateGas
  • Contract function search
  • Contract function call
• TX Indexer

[moul]

I agree with your analysis and the need for an official SDK.

I suggest dividing this topic into three parts for better organization.

Firstly, we can focus on very low-level and essential components such as raw ABCIQuery, raw TX, and account management primitives. This could be called the "Tendermint2 SDK."

Secondly, we can have a chain-specific SDK that configures and extends the TM2 SDK with chain-specific rules, commands, and helpers. This is the one I plan to use on most of my projects.

Lastly, we can explore the possibility of incorporating codegen on smart contracts to create strongly-typed clients for contracts, easily/dynamically.

[zivkovicmilos]

Thank you @dongwon8247 for opening an issue for community visibility 🙏

We have started some basic work on this topic at this WIP repo:
https://github.com/gnolang/gno-js-sdk

[moul]

We should find better naming because there will also be a "Gno SDK" to build appchains.

Maybe by using "Client" instead of "SDK", i.e., "gno.land-js-client" depending on "tm2-js-client".

[dongwon8247]

We should find better naming because there will also be a "Gno SDK" to build appchains.

Makes perfect sense

Maybe by using "Client" instead of "SDK", i.e., "gno.land-js-client" depending on "tm2-js-client".

I agree to use something with "Client" instead of "SDK".