Road to mainnet workshop(s)

[moul]

We're launching a series of workshops to refine and explain our long-term vision and strategize our roadmap to and beyond mainnet launch. These workshops will result in an actionable checklist (road to mainnet milestone), a repository of issues with additional ideas, and blogpost for wider sharing.

Steps:

• [ ] 1. Async: Share your ideas in a GitHub comment on this issue. We'll review these. <-- WE'RE HERE
• [ ] 2. Sync, recorded: We'll have a core team meeting to create a user needs-based roadmap.
• [ ] 3. Async: After creating the foundational roadmap, we'll seek more comments and inputs.
• [ ] 4. Sync, recorded: A meeting with our partners and top contributors will follow to discuss their specific needs.
• [ ] 5. Async+Sync: To ensure continuous progress, we'll update the roadmap repository regularly and propose a monthly public discussion.

Your contributions are invaluable - many thanks!

cc @gnolang/core-contributors @gnolang/tech-staff @gnolang/devrels @gnolang/tokenomics @gnolang/partners

[waymobetta]

It may be helpful to articulate the origin story of Gno.land, including some of the frustrations that we encountered from using existing systems and how these frustrations served as inspiration for a new software. This document on conceptual overviews provides a great starting point to understand some of the shortcomings that exist with various predecessor technologies (Github, AWS, Ethereum) but I wonder if these thoughts are widely known both amongst the team as well as our external community as being some of the chiefest reasons for Gno.land's creation. In other words, in a sea of information, some of this may have been lost or not yet seen despite how important it is.

Sharing a clear origin as well as defining reasons for Gno.land's development that can be posted on the website (https://gno.land/about) as well as within our external communication can build momentum, trust and an ethos that a community can be built around. Additionally, having an origin story that has a clear and direct connection to the future vision will close the loop on a product's purposeful existence as well as its differentiation compared to other offerings on the market, especially a market as diluted as the web3 space where every other day it seems a new chain comes online.

[ajnavarro]

Road to Mainnet ideas

Multiple improvements on the codebase and how to face and accomplish them

We can check here (info obtained getting all the merged PRs, and grouping changes by user and file) that is difficult to have anything merged modifying core parts of Gnoland.

I think we should talk about this, and what are the steps to improve it. Now I'll enumerate several topics that I think need improvements:

Tendermint V2 multinode

We talked about using libp2p to make it works too.

VM state storage format

If we want to have clients diversity and resilience we should simplify and improve the storage format. That format is also important to reduce used space and increase speed.

VM

The VM might benefit a lot from the work done by Marc.

Source code storage format

Same as with VM state, we should improve how source code is stored on the blockchain, and how updates can be implemented to use as less space as possible.

Do we want to keep Gno as close as possible to Go?

There were several discussions about improvements in the language itself. Even if I think we have more important things to do, I don't know if modifying Gno is a path we want to follow. If we want to do that, maybe we should change our elevator pitch about how similar Gno to Go is.

DAO framework

Creating a DAO and linking that dao to different parts of Gnoland shouldn't be difficult. Maybe we should think about a framework that will help us to integrate these DAOs with the VM and other parts that needs to get information from the blockchain itself.

Problems about too big blockchains

We should talk about this and how we want to approach a solution for that.

TL;DR

We have to define what is and what is not Gnolang:

• Similar Go workflow?
• Same Go language?
• Simple to use?
• ...

And we should think about delegating more responsibilities among the whole team.

[harry-hov]

I would like to see us prioritizing a few stuff for the mainnet:

• Define gno.mod file usage and limits
• pkg/realm versioning
• Define rules/naming for Module/Pkg/Subpkg/Realm (See: https://github.com/gnolang/gno/issues/1024))
• make gno tooling as par with go tooling

[moul]

Roadmap Workshop: Session 2 - Defining Launch Steps

Hello everyone,

We're excited to announce the second session of our Roadmap Workshop, where we'll be focusing on defining the important steps for the launch of our project. The workshop will take place on Thursday 7th sept at 5PM CET and will last for 1 hour.

To prepare for the workshop, please choose one of the following options:

1. Miro Board: Access our dedicated Miro board. Add your ideas and steps for the launch process to the board.

2. Prepared List: Create a list of important steps for the launch and bring it to the workshop.

During the workshop, we will collaborate to refine the list of launch steps, ensuring it is actionable and can be shared on GitHub issues. This will help us distribute the workload effectively among contributors.

We look forward to your active participation and valuable contributions to the workshop. Let's work together to create a successful launch plan!

[ajnavarro]

Copy and paste my notes for an opinionated roadmap ordering from here: https://hackmd.io/zWp_UlOQRZSNBJxN05e5QQ

Gno Roadmap Notes

This roadmap is getting all the ideas/concerns from gno roadmap workshop and they are ordered by teams/parallelizable sections. All the points inside a section are ordered by priority.

VM

• Simplify VM, fix bugs
• Improve gnolang UX without blockchain
• Less panics and more meaningful error messages
• Logging on the node
• Support better gas estimations and tweak the costs (x6)
• VM State storage format: solve issues and specify a format
• sync GC
• Tracing
• Support debugging for gnolang
• Reflection

Package/Realms definitions/improvements/specs

• pkg/realm versioning
• Gno packages/realms names
• Gno specs for:
  • p and r package access.
  • /r/foo/v2 naming structure
  • Default constant type for int
  • unnamed type assign named
• Improve test functions for realm dev experience
• Realm / Package Event Emits + Subscribes

User tooling

• gno as the only bin needed for gnolang development
• Improve RPC APIs
• gno.mod file usage and limits
• Dev tools integrations (gno mod, test, download libraries for local dev)
• Manage all situations for GRC20

GoR/Killing apps

• Make some killer app esp one that has a social impact like carmel
• Finalize both GoR and mainnet launch evaluation DAO analysis systems
• Contribution scoring/evaluation
• Document detailing diffs/similarities between mainnet contributions (gno.land) vs GoR.
• Have complex projects and in-depth workshops for builders to learn from

UI

• Wallet extension with session cookies UX app

Documentation

• Singular documentation resource
• Improve documentation on all modules and define a process to keep it up to date with any new feature

Tendermint v2

• Split modules (tm2/VM)
• Tendermint v2 multinode and nodes sync
• Fewer panics and more meaningful error messages
• Fix problems about too big blockchains, storage creep
• Node metrics collection using Prometheus + tracing
• Logging on the node
• Define the scope of GnoSDK

Tokenomics

• Proof of contribution specs
• Define GNOT genesis distribution
• Open-source Airdrop distribution
• Define % of fees going to ecosystem funding
• Determine if CEX's personal ATOM holdings will be treated differently than user ATOM for the GNOT airdrop

Governance

• Moderation DAO
• Integrate gov features with different parts of the stack, like the VM to check OP gas price
• Voting system for chain upgrades
• Top-level members qualifications
• Fact checker

[MichaelFrazzy]

@ajnavarro You pretty much perfectly covered my current tokenomics/GoR/governance list. We have a meeting today to cover some GoR aspects and to set a time for a regular meeting till that and Evaluation DAO are 100% good to go.

The only thing I'd add to the list on my end is finalizing the fee equation so I can simulate it, which I'll be posting a detailed issue about very soon. Side note, GNOT airdrop simulation/aggregation is essentially complete. If you go here, there is an airdrop python script that will give you an Excel sheet with airdrop results (based on the current snapshot).

The same directory has both the unique votes CSV and snapshot JSON required to run the script. I have a section in there to exclude certain addresses, this could easily be modified to adjust particular addresses if ever needed (CEXs, etc). I really appreciate you putting this together!

[thehowl]

(Not really organized by priority)

Language, tooling, standard libraries

• Create a Gno language specification, specifying precisely how realm ownership works.
• gno test, gno lint, gno doc, gno fmt, gno mod, gno get and gno repl.
• Reflection
• Port most of standard library
• Specify realm upgrades, empirically tried & tested with real-life realms.
• Decide on language features (Gnofee, type parameters, new builtin functions from 1.21...)

  Virtual Machine

• Refactor GnoVM: divide in different packages (ie. gogno, ast, preprocess, transcribe...), add godoc and external documentation, fix bugs.
• Create a full Go test suite, expanding on the existing tests/file, ensuring compatible behaviour by other VMs being developed.
• Create a CPU cycle, Allocation and Minimal Stdlib specification for alternative, compatible VM implementations
• Good VM debugging (breakpoints, virtual inspector). Descriptive and unit-tested error messages for all kind of programming errors.
• Identify a good strategy for storage of realm data (sharding/caching?)
• Sync GC

  Documentation

• Clear, centralised, understandable and play-tested getting started documentation. Understandable to people independently of their Go knowledge or Blockchain knowledge.
• Online reference for standard libraries and packages.
• Tutorials, workshops and repositories for creating intermediate dApps (chess, project management, NFT/ENS-like marketplace, proper reddit/HN clone, ...)
• Publish as a stand-alone website the Gno Playground.

  Tokenomics

• Fee equation, transaction cost estimation, fair pricing model
• PoC specification
• In general, create fair rules and systems for all parties involved: validators, end users, contributors, airdrop recipients