• Go Releaser to get mac bins
• GlobalFee
• Bundle local-ic with an embeded.FS / shim to local fs download
• Multiline deletion tag
• Uncommenter tag

Slightly being opinionated is good, we want

• generate a git init on start and commit base (auto cd into?)

make testnet:

• build binary, and docker
• local-ic spin up 26657 & IBC to another local network (future to a mainnet IBC)
• binary add keyring test for the default mnemoinics

Hello,

I successfully initiated a blockchain network with a single validator following the steps below, but I'm encountering difficulties when trying to expand the network with multiple validators. Could detailed instructions for adding multiple validators be included in the documentation? Here's the successful procedure for a single validator:

1. Generate keys for the validator: rolld keys add fastbraze
2. Initialize the node with a specific chain ID: rolld init unmar_beta0 --chain-id=44
3. Add the genesis account with a substantial stake: rolld genesis add-genesis-account <fastbraze-address> 1000000000000stake
4. Generate a genesis transaction (gentx) for the validator: rolld genesis gentx fastbraze 1000000000000stake --chain-id=44
5. Collect the genesis transactions: rolld genesis collect-gentxs
6. Start the network: rolld start

This process successfully launches a network with one validator. However, when attempting to replicate this process or modify it for adding additional validators, I run into issues, especially around the gentx step for subsequent validators, with errors indicating problems generating or recognizing gentx files properly.

For clarity and the benefit of the community, could the documentation be enhanced to include a step-by-step guide on expanding a network by adding multiple validators? Such guidance would be invaluable for those of us looking to build more complex and robust networks.

Thank you for considering this request.

• Auto Heighliner Setup
• Auto Download Local-IC from latest (v8.1.0, github API req)
• Auto gen Local-IC JSON config on new-chain (embed in simapp)
• Easy run of Local-IC with a single command. ref #12

currently we have // spawntag on every line that is module specific and will be removed if the module is within the disable flag. for single lines this is fine, but for blocks of code it would be nice to support an open/close pattern:

// open spawntag: module_name ... ... // close spawntag

we should import ignite binary for use in developing new chains. It should be optional (capable to disable)

Why

• Good for stats on it
• Marketing rough hours saved for developers

Solution

Go routine, if request fails gracefully do nothing

on action, POST to a REST API

Global data:

• Spawn version (backup: sdk version)
• Make install w/ a random UUID?

Specifics:

• num of modules created
• num of new chains
• num of test run? (ictest)

Someone from the @sonr_io team has requested ORM support

make sure to build with muscl tag

apache 2

this should work with make local image to use the created docker image and test some ibc transfers with another dockerized chain (cosmos, osmosis, etc)

The ability to spin up a new network with a standalone module basics could be very nice.

• proto/
• x/<name> with a base keeper, querier, and layout.

Then append in the app.go keepers and setup all the hassle.

This IS getting into igniteCLI territory, but it's able to be completed without much more overhead

Flow

• Another embeded.FS copies the x/ and proto/ template files. Get details from the app (such as the org name) from the go.mod. Limit flags here
• This can ONLY be run inside an active simapp copy.
• spawn module reece
• it generates the base proto files (tx, query, etc) dir and a base keeper example using those
• user modifies the proto files
• spawn module reece (this time it will see the proto is already there and make protoc-gen for the user)
• it protocgen's the files, and auto creates the types within the msg_server & keeper (or at least as much as it can)
• THen print tips for next steps / interaction?

TODO:

• Save the base proto/*.yaml folder in the original create? (then we just create new for new modules)
• Auto setup a common keeper (keys, params, etc) in app.go

• add spawn module new name --middleware scaffolding of middlewars w/ Justin's ICS27 template repo

not sure why but when using heighliner to build, it's not picking up the fiels in the folder? used Juno as reference so I know it works, but it's not even building the binary

May need to modify chains.yml to be more specific like so:

- name: project
  github-organization: MY-ORG
  github-repo: myproject
  dockerfile: cosmos
  build-target: make install
  build-dir: ./
  build-env:
    - BUILD_TAGS=muslc
  binaries:
    - /go/bin/appd

ref: current make local-image uses standard docker builder.

also both break on wasmd builds because static linking stuff
permissiones for /tmp

Short videos (<5min) showing how to use Spawn. Then basics of Cosmos SDK module developnent (maybe a quick OTC module using multiple local denoms). Similar to https://cosmology.zone/learn

Maybe not in this order, but:

• New Chain, Config options, and github upload
• Local-Interchain testnet
• Interchaintest walkthrough
• Gitbub Action CI
• Basics of a CosmosSDK chain
• Creating a base Module
• Quick module logic impl
• Deploying to the cloud
• Add / import external modules by name -> app.go
• Import an SDK module from the Cosmos-SDK (maybe have this be automatic? idk)
• Software Upgrade + docs w/ how to perform (maybe a Spawn cmd for handler generation?)

Request re: SDK Concept Docs

"Honestly it would be great to have actual exercises after each of the reading materials. I do know that there is code to look at, but I’d personally benefit from each reading module having either some problems to solve or even some code that we can continue building on top of throughout all of the readings"

My thoughts

• For concepts; give examples in multiple languages (Go, Python, TS/JS) to showcase it in standard digestible terms. Let's people play with things (i.e. Merkle Root, basics of a blockchain / messages / tx, etc)
• Have bad modules / setup apps in git to help people walk through and debug concepts. (with solutions too)
• 1 program / concept should walk you through from concepts to our future interchain app.

This module would allow people to use the chain for multisig coordination:

i.e. allows users to post txns that need to be signed and to also post signatures to the chain.

preferably polaris, but we should at least support ethermint

https://hackmd.io/81qB_WTTTcSh3B2Lde8BqA

Slate
Spawn

Modules

• packetforward
• PoA
• TokenFactory
• GlobalFee (0 fees for testnets, test with ictest)
• TiaBlob

Opt-In

• 08 Wasm Light Client
• Skip's POB / block-sdk
• Async ICQ
• IBC-Hooks
• OJO Oracle
• https://github.com/ojo-network/ojo
• https://github.com/Stride-Labs/ibc-rate-limiting (v50 branch)
  • E2E test
• Osmosis GAMM (apache-2, upgrade from dymensionxyz ?)
• Ignite-CLI
• EVM
  • Polaris w/ a separate EVM simapp most likely
  • Ethermint v50 from cro (off)

on proto-stub, dot his too as a nice to have base

func MsgSetServiceName() *cobra.Command {
	cmd := &cobra.Command{
		Use:   "set [name]",
		Short: "Set the nameservice value",
		Args:  cobra.ExactArgs(1),
		RunE: func(cmd *cobra.Command, args []string) error {
			cliCtx, err := client.GetClientTxContext(cmd)
			if err != nil {
				return err
			}

			senderAddress := cliCtx.GetFromAddress()

			msg := &types.MsgSetServiceName{
				Sender: senderAddress.String(),
				Name:   args[0],
			}

			return tx.GenerateOrBroadcastTxCLI(cliCtx, cmd.Flags(), msg)
		},
	}

	flags.AddTxFlagsToCmd(cmd)
	return cmd
}

and also add to txCmd.AddCommand

order:

• add interchaintest Basic test default and replaces
• Don't abstract away make commands within spawn. (Could add to a spawn help though)
• Cleanup everything.
• Comments on #23
• Builder pattern for parser
• Additive CLI UI picker - using flags should ignore this UI
• Regex: find addresses & replace with new prefixes automatically within files
• pretty / correct logging

https://github.com/CosmWasm/wasmvm/releases/tag/v2.0.0

spawn upgrade cosmwasm2 to perform a migration

also fix capabilities to work after linting

• Add more test setup for keeper (keeper_test.go). ref: manifest / Juno
• UpdateParams should have the authority (by default use the gov auth account) and then have a todo as well

Part 1

• go mod download & cache
• ensure go unit test passes
• ensure build passes & start chain from test_node script
• Ensure no references to disabled modues within the new user facing chains

Part 2

• build chains of different types (i.e. change bin, prefix). randomization of modules. Grep no instances in each

https://github.com/cosmos/iavl/releases/tag/v1.0.1

Think about what a deploy testnet GitHub action might look like and what it would do.

depends on #49

SDK v50 chain, and we have a v50 branch here for spawn. It will have a go.mod (in the simapp) we maintained with non state breaking versions. This would be saved within the spawn binary FS.

We can have a command that reads the internal latest FS go.mod, and persist the version bump changes to the downstream repo. These upstreams would have been tested heavily before being added
spawn bump-deps. Could also do for CI. Removes dependabot need

https://github.com/josharian/impl ?

Flow: User generates a new module. They modify the proto, then make proto-gen.
Issue: The types are generated BUT the msg_server does not have the correct values. Bad UX

Solution

• Read in the proto/ directory values for a module
• Parse the proto files, and get the query & Tx message types.
• find msg_server and querier .go files in the keeper, and modify them. They would be the files which have the MsgServer & Querier types

ref: https://github.com/hashicorp/go-plugin

goal:

• Take a private binary and put it in some directory for spawn (i.e. GOPATH, ~/.spawn, etc)
• Load & use features from here from a closed source solution without having to fork spawn out

• https://github.com/rollchains/spawn/actions/runs/7856434695/job/21439188798

scm releases: failed to publish artifacts: failed to upload spawn_0.0.1-testperm_darwin_arm64.tar.gz after 10 tries: POST https://uploads.github.com/repos/strangelove-ventures/spawn/releases/141481979/assets?name=spawn_0.0.1-testperm_darwin_arm64.tar.gz: 307 Moved Permanently []

We want the ability to remove and add modules. There are a few approaches

v1: Only allow setting modules on start. i.e. POA enabled, then use regex/a template to remove said PoA if the user wants to use PoS instead

1. Start with a simapp that has all standard modules setup (tokenfactory, wasm, ibc, PoA). On create pick like Go functionality for modules to remove (all are already selected to start). On uncheck of the box, remove all occurrences. Only works on start.
2. Default simapp (wasmd), with option to add other modules. I think template files are the best approach. This will require comments ONLY on the maintainer side (i.e. in this repo), not on other chains. This is done by regex matching to find where to modify. Could use Go's parser & ast. may be overkill
3. Force app_v2.go requirements, and no auto generation. Just modify 2 lines done (unsure how this handles testing and interaction due to generalized dep inject)

Use keyring test or file or something else other than OS keyring

and set the defaults
on chain create, set the chain-id by default. other things from configs.json etc

2 choices for version support for simapp:

1. We provide support permutations for a range of different versions of cosmos sdk, ibc-go, and cometBFT
2. We make an opinionated stance and direct users to only the latest stable versions

Unsure what gh can handle. Manual process for releases is most scaleable. Biggest pitfalls should be in internal CI? (unless we can fit all then cool)

• Add ICTest test on base chain (just Basic to ensure it runs?)

Update v0.50.* in the README to the new tag name before tagging!

make sure README works as expected manually (i.e. clear wallet keys, etc)

Approach 0 - Manual Checks Privately

Should write a script / document for this. May be the best solution for now (do off the branch before tagging)

# run the cmd, and in vscode press publish branch (auto creates private/public repo for you).
# maybe also run a go test / docker build here?

# standard
spawn new base --bypass-prompt --bech32=abcd --bin=aaaaad --denom=uxyz --org=strangelove && code base/

# nothing at all, just cosmos
spawn new minimal --disable=proof-of-authority,tokenfactory,globalfee,ibc-packetforward,cosmwasm,ignite,wasm-light-client --bech32=abcd --bin=aaaaad --denom=uxyz --org=strangelove && code minimal/

# only cosmwasm
spawn new mycw --disable=tokenfactory,poa,globalfee,ibc-packetforward --bech32=abcd --bin=aaaaad --denom=uxyz --org=reecepbcups && code mycw/

# wasmlc no wasm
spawn new mywlc --disable=tokenfactory,poa,globalfee,ibc-packetforward,cosmwasm && code mywlc/

# TODO: ibc-ratelimit, ics

# mixes
spawn new randmix --disable=globalfee,wasmlc,ignite && cd randmix && go test ./... && cd .. && rm -rf randmix/
spawn new randmix --disable=wasmlc,tokenfactory && cd randmix && go test ./... && cd .. && rm -rf randmix/
spawn new randmix --disable=wasmlc,wasm && cd randmix && go test ./... && cd .. && rm -rf randmix/
spawn new randmix --disable=poa,globalfee && cd randmix && go test ./... && cd .. && rm -rf randmix/
spawn new randmix --disable=poa,globalfee && cd randmix && go test ./... && cd .. && rm -rf randmix/
spawn new randmix --disable=tokenfactory,poa,packetforward && cd randmix && go test ./... && cd .. && rm -rf randmix/
spawn new randmix --disable=packetforward,cosmwasm,ignite,ignite && cd randmix && go test ./... && cd .. && rm -rf randmix/
spawn new randmix --disable=cosmwasm,cosmwasm,wasm-light-client && cd randmix && go test ./... && cd .. && rm -rf randmix/

# validate ictest testnets with base install, and one with all (make testnet)

Approach 1

Chain 1:

• defaults, no changes. just change binary, org, token, & wallet prefix
• go test
• validate the chain starts with make sh-testnet ? (in the backrgound)
• make local-image
• seperate threads, run make ictest-basic, ictest-poa

Chain2: (opposite of what is the default). Keep all default flags

• Yes: Wasm, Light Client, IgniteCLI. No: GlobalFee, TokenFactory, PoA
• go test
• make local-image
• make ictest-basic, ictest-wasm

Approach 2

• Randomize matrixes

Approach 3

• Gen all matrix permutations (disabled and enabled), then just go test ./…

for PoA chains, maybe allow the admin(s) to halt all validators vs validators needing to do it on their own
If a security patch needs to be impl, all vals can be halted at a height by the admin

this demo should take the user from only having Go installed to creating a new chain, testing txs, and connecting other local chains (osmosis and cosmoshub) and test ibc txs

• chain with new module
• IBC setup and Tx

If copying over a cosmos/ proto, make sure to handle that when trying to move (mv cosmos/mint instead of trying just mv mint. ref: burnt).

nested package proto package names need support ->

custom_modules=$(find . -name 'module' -type d -not -path "./proto/*") how to get nested directories?

demo spin up of cosmoshub testnet and ibc transfers between this and the newly spawned chain

Overview

• Remove ictest files if a module is removed

Test

If no link provided, use Juno as ref

• PoA (manifest for latest v8.1.0 ictest)
• CosmWasm
• Tokenfactory
• PacketForward (A, B, C. Ensure A -> C works for less flakeyness)

TODO

• Add / remove ICS as expected with tags
• Add new 'staking' option. This feature is on by default but hidden
  • If ICS is used, then staking is disabled, removes all references for staking. \
  • Also remove Distr, Mint, etc.
• Integrate Interchaintest w/ simple ICS test ( strangelove-ventures/interchaintest#1088 )
• Add test_ics_node.sh instead of test_node.sh w/ Stide's provider hack
• CI: Run test_ics_node.sh for ics chain (matrix?)
• Speed up CI
• Unit Test (ref: stride, neutron)
• rename to ics_basic_test.go - see if we can abstract in setup.go so we can reuse standard test instead of new ones
• Update to ICTest v8.3.0 + IBC validation (from upstream ICT)
• Local Interchain proper generation (remove default)
• In UI, if ICS selected, deselect POA

Test Basic

make install && rm -rf testics1/
spawn new testics1 --disable=poa,tf,globalfee,packetforward,ibc-ratelimit,cw,wasm-lc,ignite-cli

spawn new chain1 --disable=ics
spawn new chain2

having an opt-in enable flag would be too verbose to the current opt-out disable flag, but this is still a suboptimal UX.

I don't have a solution in mind, but we should brainstorm on better designs for users to select modules

if not installed, prompt the user then do a wget to a local directory. Use one of the local paths (or the users $GOPATH/bin) for download.

Don't think this needs to be within spawn, but rather just in the spawn child chain makefile

we need to do the following to open source the repo & release spawn

Part 1

• Move modules -> Strangelove org & namespace from personal. Tag latest as v0.50
  • #81
  • #82
• Verify rollchains namespace is used everywhere (#78)
• Release GlobalFee, Tokenfactory, and PoA v0.50 + latest PFM
• Tag v8.2 interchaintest w/ PR 1006 for interaction. Ensure that’s used in make file download
• Re-review, cleanup todos
• Push new generated chains to CI passing - #87
• Move to main

Part 2

• Replace readme main video -> the new one from jack
• better disabled UX - #89
• Make main branch 0.50.x (no v) or release/v0.50 ? & set as the default branch
• Update readme to use local-ic interact instead of curl
• Push new generated chains to CI passing (again) + make testnet
  • minimal
  • base
  • mywaslc
  • mycw
• Tag spawn v0.50.0
• Point website to spawn
• Open Source
• Add to https://github.com/cosmos/awesome-cosmos "Templates" section

https://github.com/Stride-Labs/ibc-rate-limiting

video walk through / written docs

ref #119 as a good example

Spawn should support easy commands to spin up local testnets and relayers for various chains, create ibc channels, and test ibc txs back and forth.

for example:
spawn local-ic add ibc-chain osmosis
spawn local-ic add ibc-chain celestia

Then Spawn should spin up these chains, instantiate the ibc channels, and then provide some easy commands to test the channels like:
rolld query ibc channel client-state transfer channel- ...
rolld tx ibc-transfer transfer [PORT_ID] [CHANNEL_ID] [TO-ADDRESS-ON-DST-CHAIN] [amount] --from acc_X --chain-id [SRC-CHAIN-ID]