Gno Core Issue Tracker

[dongwon8247]

Description

This issue tracker contains a list of things that Onbloc and Gnoswap need from the Gnoland Core side. Its purpose is to centralize all the issues in one place for better coordination and management.

Major Features

• 1. Inter contract interaction #757

  • Usecase: Dapps that need to manage GRC20 & GRC721 tokens dynamically (i.g. DeFi dapp)
  • Related to:
    • WIP feat: improve grc20/foo20 APIs gnolang/gno#952
    • [WIP]feat: Protocol to support contract-contract interaction gnolang/gno#473
  • Completed in:
    • chore: add contract-contract interation with ownership example gnolang/gno#1262
    • feat: grc20 dynamic call with registered interface gnolang/gno#1275

• 2. Emit & event function with WS & subscribe support #575 (like eth_subscribe, eth_unsubscribe in Ethereum)

  • Usecase: To subscribe block/transaction events from TM2 for an indexer, and realms for ongoing events
  • Related to:
    • feat: add file-based transaction indexing gnolang/gno#546
    • feat: event & emit in gno gnolang/gno#853

• 3. Porting Go packages to pure Gno stdlibs, #33, 1267

  • Usecase: Porting essential Go packages such as bigint, bytes, reflect, encoding, json parser, testing, and io
  • Completed in:
    • Add bigint feat: native bigint using math/big.Int gnolang/gno#764
    • Replace io/ioutil to os chore: remove deprecated io/ioutil methods gnolang/gno#1277
    • Add hash feat: add hash  gnolang/gno#1273
    • Add encoding feat(stdlibs): add encoding, encoding/{base32,binary,csv} gnolang/gno#1290
    • Add io/fs feat: Porting io/fs package gnolang/gno#1323
    • Add json parser feat: byte slice JSON parser gnolang/gno#1415
    • Add u/int256 feat(p/uint256): uint256 gnolang/gno#1778 feat(p/int256): int256 gnolang/gno#1848
    • Add unicode/utf16 feat(stdlib): add unicode/utf16 pacakge gnolang/gno#1764
    • Adding more packages feat(stdlibs): Fuzz for String gnolang/gno#1809

• 4. Lead Multi-node Testnet Initiative #9, #863

  • Usecase: Lead multi-node testnet initiative on a separate testnet with community validators
  • Related to:
    • WIP chore: guidelines for multinode testnet experimentation gnolang/gno#871
    • A simple implementation for multi-validator  gnolang/gno#889

Not required for Mainnet

• 5. Upgradable Realms #694
  • Usecase: Proxy pattern and storage migration for realms
  • Related to: (Not being addressed at the moment)

Minor Bugs

• 1. Block data sync-related issues #863
  • Usecase: Operating the full node (For teams/individuals that need an indexer)
  • Related to: chore(deployments): enable empty blocks creation on staging gnolang/gno#899
• 2. Support skipping timestamp in test case feat: support timestamp skipping in test cases gnolang/gno#569
  • Usecase: To test logic that depends on how much time has been passed
• 3. PrevRealm testing bug fix #891
  • Usecase: To fix a problem of having different results in gno test and gnoland & gnokey
  • Related to: fix(gnovm): PrevRealm in _test files gnolang/gno#896
• 4. Change the banker module #875
  • Usecase: To fix a bug of minting additional coins using banker.
  • Related to: feat(stdlibs/std)!: namespace minted coins with realm path gnolang/gno#875 fix: minting additional GNOTs  gnolang/gno#393
• You can find more bug fixes here: 🤝🏻 Partner: Onbloc (view)

[r3v4s]

6. Support skipping timestamp in test cases. gnolang#569
- Usecase: testing logics that depends on how much time have been passed
- Depends on: nothing at this moment

Merged with the main comment for better visibility

[r3v4s]

7. PrevRealm
- related: gnolang#896
- issue: result is different from gno test and gnoland & gnokey
- can be by pass with, gnolang#891

Merged with the main comment for better visibility

[r3v4s]

8. Upgradable Contract
- proxy pattern
- storage migration

Merged with the main comment for better visibility

[r3v4s]

Details of the Contract Interaction Issue

1. When importing token realms

Current: Import tokens manually (https://github.com/gnoswap-labs/gnoswap/blob/d624686b1d3af19313ab407ac3d626ec87e6c68d/pool/pool_manager.gno#L7-L8)

import (
  "std"
  "strconv"
  
  foo "gno.land/r/foo" // Import token0 manually
  bar "gno.land/r/bar" // Import token1 manually
  
  "gno.land/p/demo/ufmt"
)

Ideally with contract interaction functionality:

no need to import each token

2. When creating a pool

Current: Set token0 as foo, and token1 as bar manually, which are imported from above (https://github.com/gnoswap-labs/gnoswap/blob/d624686b1d3af19313ab407ac3d626ec87e6c68d/pool/pool_manager.gno#L119-L135)

return &Pool{
  token0:               foo.GetGRC20(),
  token1:               bar.GetGRC20(),
  balances:             balances,
  fee:                  fee,
  tickSpacing:          tickSpacing,
  maxLiquidityPerTick:  maxLiquidityPerTick,
  slot0:                slot0,
  feeGrowthGlobal0X128: 0,
  feeGrowthGlobal1X128: 0,
  protocolFees:         protocolFees,
  liquidity:            0,
  ticks:                Ticks{},
  tickBitmaps:          TickBitmaps{},
  positions:            Positions{},
}

Ideally with contract interaction functionality:

return &Pool{
  token0:               std.Call("gno.land/r/foo", GetGRC20) // Example with std.Call
  token1:               std.Call("gno.land/r/bar", GetGRC20) // Example with std.Call
  balances:             balances,
  fee:                  fee,
  tickSpacing:          tickSpacing,
  maxLiquidityPerTick:  maxLiquidityPerTick,
  slot0:                slot0,
  feeGrowthGlobal0X128: 0,
  feeGrowthGlobal1X128: 0,
  protocolFees:         protocolFees,
  liquidity:            0,
  ticks:                Ticks{},
  tickBitmaps:          TickBitmaps{},
  positions:            Positions{},
}

3. When swapping tokens

Current: Same as creating a pool, we have to set token0 as foo, and token1 as bar manually, which are imported from above (swap token0 & swap token1)

if amount1 < 0 {
  // handle token1
  bar.Transfer(a2u(recipient), uint64(-1*amount1))
}

// handle token0
from := a2u(GetOrigCaller()) // token should be transferred from actual user(GetOrigCaller), not from the realm(PrevRealm)
to := a2u(GetOrigPkgAddr())

foo.TransferFrom(from, to, uint64(amount0))

Ideally with contract interaction functionality:

if amount1 < 0 {
  // handle token1
  pool.token1.Transfer(a2u(recipient), uint64(-1*amount1))
}

// handle token0
from := a2u(GetOrigCaller()) // token should be transferred from actual user(GetOrigCaller), not from the realm(PrevRealm)
to := a2u(GetOrigPkgAddr())

pool.token0.TransferFrom(from, to, uint64(amount0))

---

Problems

• We have to import all of the existing token realms manually before creating a pool, and supporting a swap
• We can't support token realms that didn't exist when deploying the pool contract
  • If we're to support new token realms after the pool contract deployment, then we have to manually import it in a new pool contract and re-deploy it, which causes a path conflict issue, and contract upgradability issue (storage migration)

What Inter-contract Functionality Unlocks

• We can remove all of the hard-coded values (foo, bar) and call a contract's functions without manually importing it, just like EVM's abi.Call.
  • We can set token pkg_path value into the pool structure and dynamically call the function using token pkg_path
• We can support new token realms for creating a pool and swapping without re-deploying the pool contract

Moving Forward

• Based on @moul's work #938, #952, and @jaekwon's comment on the inter contract call issue, having banker20 in the GRC20 spec to support GRC20 tokens to be used dynamically would be the way to resolve the inter contract issue.
• We will study more on the issue based on Manfred's ongoing work #952, and try to come up with suggestions next time.
• Any advice on the direction to move this forward would be appreciated.

[moul]

For contract-contract interaction without modifying the gnovm (without adding std.Call or IBC), I propose the following plans:

Option 1: Create a main contract, let's call it r/gnoswap/hub, which includes a RegisterSwapper function. This function can be called from new contracts that you add later, such as r/gnoswap/swapper-foo20. During the init() phase, the new contracts can register themselves on the hub like this: hub.RegisterSwapper("foo20", mySwapper), where mySwapper is a global variable implementing the hub.Swapper interface. Subsequently, the hub can utilize its local registry of tokens and call swapper methods without needing to import them.

Edit: gnolang#1262

Option 2: Consider code generation to register new contracts for each token or potentially for each token-pair. Your frontend would need to be aware of which contract to call depending on the scenario. These contracts could import a hub/keeper to attempt centralizing the GRC20s in a semi-permissionless manner. The goal of the hub/keeper is to provide a central address for both native tokens and GRC20s (you can use the Approve method to delegate GRC20 management to your keeper).