Merge branch 'main' into chore/new-network-path

ignite · Nov 8, 2024 · 095bc7d · 095bc7d
2 parents cdec515 + 901f402
commit 095bc7d
Show file tree

Hide file tree

Showing 52 changed files with 1,614 additions and 388 deletions.
diff --git a/changelog.md b/changelog.md
@@ -18,6 +18,7 @@
 - [#4131](https://github.com/ignite/cli/pull/4131) Support `bytes` as data type in the `scaffold` commands
 - [#4300](https://github.com/ignite/cli/pull/4300) Only panics the module in the most top function level
 - [#4327](https://github.com/ignite/cli/pull/4327) Use the TxConfig from simState instead create a new one
+- [#4377](https://github.com/ignite/cli/pull/4377) Add multi node (validator) testnet.
 - [#4326](https://github.com/ignite/cli/pull/4326) Add `buf.build` version to `ignite version` command
 - [#4362](https://github.com/ignite/cli/pull/4362) Scaffold `Makefile`
 - [#4289](https://github.com/ignite/cli/pull/4289) Cosmos SDK v0.52 support

diff --git a/contributing.md b/contributing.md
@@ -4,8 +4,6 @@ Before submitting a PR to the Ignite CLI repository, please review and follow th
 
 If you have suggestions or want to propose changes to these guidelines, start a new [Discussion topic](https://github.com/ignite/cli/discussions/new) to gather feedback.
 
-For setup instructions, see [Set Up Your Ignite CLI Development Environment](dev-env-setup.md).
-
 To contribute to docs and tutorials, see [Contributing to Ignite CLI Docs](https://docs.ignite.com/contributing).
 
 We appreciate your contribution!
@@ -120,8 +118,6 @@ We use Git Flow as our branch strategy, with each MAJOR release linked to a mile
 - **Next Milestone:**  
   The **Next** milestone is used for issues or features that are not tied to a specific release but are still relevant to the project’s roadmap. These issues will be addressed when higher-priority work has been completed, or as part of future planning.
 
-Check the [project board](https://github.com/ignite/cli/projects/7) to see what we're working on and what’s planned.
-
 ## Issue Title Conventions and Labeling
 
 To maintain consistency across issues and PRs, follow these guidelines for issue titles:

diff --git a/docs/docs/02-guide/04-ibc.md b/docs/docs/02-guide/04-ibc.md
@@ -26,7 +26,7 @@ end-to-end, connection-oriented, stateful protocol provides reliable, ordered,
 and authenticated communication between heterogeneous blockchains.
 
 The [IBC protocol in the Cosmos
-SDK](https://ibc.cosmos.network/main/ibc/overview.html) is the standard for the
+SDK](https://ibc.cosmos.network/main/ibc/overview) is the standard for the
 interaction between two blockchains. The IBCmodule interface defines how packets
 and messages are constructed to be interpreted by the sending and the receiving
 blockchain.
@@ -223,48 +223,48 @@ the `msg.Creator` value to the IBC `packet`.
 package keeper
 
 func (k msgServer) SendIbcPost(goCtx context.Context, msg *types.MsgSendIbcPost) (*types.MsgSendIbcPostResponse, error) {
-	// validate incoming message
-	if _, err := k.addressCodec.StringToBytes(msg.Creator); err != nil {
-		return nil, errorsmod.Wrap(sdkerrors.ErrInvalidAddress, fmt.Sprintf("invalid address: %s", err))
-	}
-
-	if msg.Port == "" {
-		return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet port")
-	}
-
-	if msg.ChannelID == "" {
-		return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet channel")
-	}
-
-	if msg.TimeoutTimestamp == 0 {
-		return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet timeout")
-	}
-
-	// TODO: logic before transmitting the packet
-
-	// Construct the packet
-	var packet types.IbcPostPacketData
-
-	packet.Title = msg.Title
-	packet.Content = msg.Content
-	// highlight-next-line
-	packet.Creator = msg.Creator
-
-	// Transmit the packet
-	ctx := sdk.UnwrapSDKContext(goCtx)
-	_, err := k.TransmitIbcPostPacket(
-		ctx,
-		packet,
-		msg.Port,
-		msg.ChannelID,
-		clienttypes.ZeroHeight(),
-		msg.TimeoutTimestamp,
-	)
-	if err != nil {
-		return nil, err
-	}
-
-	return &types.MsgSendIbcPostResponse{}, nil
+ // validate incoming message
+ if _, err := k.addressCodec.StringToBytes(msg.Creator); err != nil {
+  return nil, errorsmod.Wrap(sdkerrors.ErrInvalidAddress, fmt.Sprintf("invalid address: %s", err))
+ }
+
+ if msg.Port == "" {
+  return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet port")
+ }
+
+ if msg.ChannelID == "" {
+  return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet channel")
+ }
+
+ if msg.TimeoutTimestamp == 0 {
+  return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet timeout")
+ }
+
+ // TODO: logic before transmitting the packet
+
+ // Construct the packet
+ var packet types.IbcPostPacketData
+
+ packet.Title = msg.Title
+ packet.Content = msg.Content
+ // highlight-next-line
+ packet.Creator = msg.Creator
+
+ // Transmit the packet
+ ctx := sdk.UnwrapSDKContext(goCtx)
+ _, err := k.TransmitIbcPostPacket(
+  ctx,
+  packet,
+  msg.Port,
+  msg.ChannelID,
+  clienttypes.ZeroHeight(),
+  msg.TimeoutTimestamp,
+ )
+ if err != nil {
+  return nil, err
+ }
+
+ return &types.MsgSendIbcPostResponse{}, nil
 }
 ```
 
@@ -315,11 +315,11 @@ Then modify the `OnRecvIbcPostPacket` keeper function with the following code:
 package keeper
 
 func (k Keeper) OnRecvIbcPostPacket(ctx sdk.Context, packet channeltypes.Packet, data types.IbcPostPacketData) (packetAck types.IbcPostPacketAck, err error) {
-	packetAck.PostId, err = k.PostSeq.Next(ctx)
-	if err != nil {
-		return packetAck, err
-	}
-	return packetAck, k.Post.Set(ctx, packetAck.PostId, types.Post{Title: data.Title, Content: data.Content})
+ packetAck.PostId, err = k.PostSeq.Next(ctx)
+ if err != nil {
+  return packetAck, err
+ }
+ return packetAck, k.Post.Set(ctx, packetAck.PostId, types.Post{Title: data.Title, Content: data.Content})
 }
 ```
 
@@ -339,33 +339,33 @@ from the packet.
 package keeper
 
 func (k Keeper) OnAcknowledgementIbcPostPacket(ctx sdk.Context, packet channeltypes.Packet, data types.IbcPostPacketData, ack channeltypes.Acknowledgement) error {
-	switch dispatchedAck := ack.Response.(type) {
-	case *channeltypes.Acknowledgement_Error:
-		// We will not treat acknowledgment error in this tutorial
-		return nil
-	case *channeltypes.Acknowledgement_Result:
-		// Decode the packet acknowledgment
-		var packetAck types.IbcPostPacketAck
-		if err := types.ModuleCdc.UnmarshalJSON(dispatchedAck.Result, &packetAck); err != nil {
-			// The counter-party module doesn't implement the correct acknowledgment format
-			return errors.New("cannot unmarshal acknowledgment")
-		}
-
-		seq, err := k.SentPostSeq.Next(ctx)
-		if err != nil {
-			return err
-		}
-
-		return k.SentPost.Set(ctx, seq,
-			types.SentPost{
-				PostId: packetAck.PostId,
-				Title:  data.Title,
-				Chain:  packet.DestinationPort + "-" + packet.DestinationChannel,
-			},
-		)
-	default:
-		return errors.New("the counter-party module does not implement the correct acknowledgment format")
-	}
+ switch dispatchedAck := ack.Response.(type) {
+ case *channeltypes.Acknowledgement_Error:
+  // We will not treat acknowledgment error in this tutorial
+  return nil
+ case *channeltypes.Acknowledgement_Result:
+  // Decode the packet acknowledgment
+  var packetAck types.IbcPostPacketAck
+  if err := types.ModuleCdc.UnmarshalJSON(dispatchedAck.Result, &packetAck); err != nil {
+   // The counter-party module doesn't implement the correct acknowledgment format
+   return errors.New("cannot unmarshal acknowledgment")
+  }
+
+  seq, err := k.SentPostSeq.Next(ctx)
+  if err != nil {
+   return err
+  }
+
+  return k.SentPost.Set(ctx, seq,
+   types.SentPost{
+    PostId: packetAck.PostId,
+    Title:  data.Title,
+    Chain:  packet.DestinationPort + "-" + packet.DestinationChannel,
+   },
+  )
+ default:
+  return errors.New("the counter-party module does not implement the correct acknowledgment format")
+ }
 }
 ```
 
@@ -376,17 +376,17 @@ posts. This logic follows the same format as `sentPost`.
 
 ```go title="x/blog/keeper/ibc_post.go"
 func (k Keeper) OnTimeoutIbcPostPacket(ctx sdk.Context, packet channeltypes.Packet, data types.IbcPostPacketData) error {
-	seq, err := k.TimeoutPostSeq.Next(ctx)
-	if err != nil {
-		return err
-	}
-
-	return k.TimeoutPost.Set(ctx, seq,
-		types.TimeoutPost{
-			Title: data.Title,
-			Chain: packet.DestinationPort + "-" + packet.DestinationChannel,
-		},
-	)
+ seq, err := k.TimeoutPostSeq.Next(ctx)
+ if err != nil {
+  return err
+ }
+
+ return k.TimeoutPost.Set(ctx, seq,
+  types.TimeoutPost{
+   Title: data.Title,
+   Chain: packet.DestinationPort + "-" + packet.DestinationChannel,
+  },
+ )
 }
 ```
 

diff --git a/docs/docs/03-CLI-Commands/01-cli-commands.md b/docs/docs/03-CLI-Commands/01-cli-commands.md
@@ -3666,7 +3666,7 @@ Start a testnet local
 
 **Synopsis**
 
-The commands in this namespace allow you to start your local testnet for development purposes. Currently there is only one feature to create a testnet from any state network (including mainnet).
+The commands in this namespace allow you to start your local testnet for development purposes. 
 
 
 The "in-place" command is used to create and start a testnet from current local net state(including mainnet).
@@ -3675,9 +3675,12 @@ We can create a testnet from the local network state and mint additional coins f
 
 During development, in-place allows you to quickly reboot the chain from a multi-node network state to a node you have full control over.
 
+The "multi-node" initialization and start command is used to set up and launch a multi-node network, allowing you to enable, disable, and providing full interaction capabilities with the chain. The stake amount for each validator is defined in the config.yml file.
+
 **SEE ALSO**
 
 * [ignite testnet in-place](#ignite-testnet-in-place)	 - Create and start a testnet from current local net state
+* [ignite testnet multi-node](#ignite-testnet-multi-node)	 - Initialize and provide multi-node on/off functionality
 
 
 ## ignite testnet in-place 
@@ -3725,6 +3728,57 @@ ignite chain debug [flags]
   -c, --config string   path to Ignite config file (default: ./config.yml)
 ```
 
+## ignite testnet multi-node
+
+Initialize and start multiple nodes
+
+**Synopsis**
+
+The "multi-node" command allows developers to easily set up, initialize, and manage multiple nodes for a testnet environment. This command provides full flexibility in enabling or disabling each node as desired, making it a powerful tool for simulating a multi-node blockchain network during development.
+
+By using the config.yml file, you can define validators with custom bonded amounts, giving you control over how each node participates in the network:
+
+```
+                  validators:
+                        - name: alice
+                        bonded: 100000000stake
+                        - name: validator1
+                        bonded: 100000000stake
+                        - name: validator2
+                        bonded: 200000000stake
+                        - name: validator3
+                        bonded: 300000000stake
+
+```
+
+Each validator's bonded stake can be adjusted according to your testing needs, providing a realistic environment to simulate various scenarios.
+
+The multi-node command not only initializes these nodes but also gives you control over starting, stopping individual nodes. This level of control ensures you can test and iterate rapidly without needing to reinitialize the entire network each time a change is made. This makes it ideal for experimenting with validator behavior, network dynamics, and the impact of various configurations.
+
+All initialized nodes will be stored under the `.ignite/local-chains/<appd>/testnet/` directory, which allows easy access and management.
+
+
+Usage
+
+```
+ignite testnet multi-node [flags]
+```
+
+**Options**
+
+```
+  -r, --reset-once              reset the app state once on init
+  --node-dir-prefix             dir prefix for node (default "validator")
+  -h, --help                    help for debug
+  -p, --path string             path of the app (default ".")
+```
+
+**Options inherited from parent commands**
+
+```
+  -c, --config string   path to Ignite config file (default: ./config.yml)
+```
+
 **SEE ALSO**
 
 * [ignite](#ignite)	 - Ignite CLI offers everything you need to scaffold, test, build, start testnet and launch your blockchain
diff --git a/docs/docs/06-migration/v0.24.0.md b/docs/docs/06-migration/v0.24.0.md
@@ -193,7 +193,7 @@ If you have IBC-enabled modules (for example, added with `ignite scaffold module
 the following changes to the source code.
 
 Cosmos SDK expects IBC modules
-to [implement the `IBCModule` interface](https://ibc.cosmos.network/main/ibc/apps/ibcmodule.html). Create a `IBCModule`
+to [implement the `IBCModule` interface](https://ibc.cosmos.network/main/ibc/apps/ibcmodule/). Create a `IBCModule`
 type that embeds the module's keeper and a method that returns a new `IBCModule`. Methods in this file will be defined
 on this type.
 

diff --git a/docs/docs/08-references/01-cli.md b/docs/docs/08-references/01-cli.md
@@ -3437,6 +3437,7 @@ Start a testnet local
 
 * [ignite](#ignite)	 - Ignite CLI offers everything you need to scaffold, test, build, and launch your blockchain
 * [ignite testnet in-place](#ignite-testnet-in-place)	 - Create and start a testnet from current local net state
+* [ignite testnet multi-node](#ignite-testnet-multi-node)	 - Initialize and provide multi-node on/off functionality
 
 
 ## ignite testnet in-place
@@ -3471,6 +3472,60 @@ ignite testnet in-place [flags]
 * [ignite testnet](#ignite-testnet)	 - Start a testnet local
 
 
+## ignite testnet multi-node
+
+Initialize and provide multi-node on/off functionality
+
+**Synopsis**
+
+Initialize the test network with the number of nodes and bonded from the config.yml file::
+			...
+                  validators:
+                        - name: alice
+                        bonded: 100000000stake
+                        - name: validator1
+                        bonded: 100000000stake
+                        - name: validator2
+                        bonded: 200000000stake
+                        - name: validator3
+                        bonded: 300000000stake
+
+
+			The "multi-node" command allows developers to easily set up, initialize, and manage multiple nodes for a 
+			testnet environment. This command provides full flexibility in enabling or disabling each node as desired, 
+			making it a powerful tool for simulating a multi-node blockchain network during development.
+
+			Usage:
+					ignite testnet multi-node [flags]
+
+		
+
+		
+
+```
+ignite testnet multi-node [flags]
+```
+
+**Options**
+
+```
+      --check-dependencies       verify that cached dependencies have not been modified since they were downloaded
+      --clear-cache              clear the build cache (advanced)
+  -h, --help                     help for multi-node
+      --home string              directory where the blockchain node is initialized
+      --node-dir-prefix string   prefix of dir node (default "validator")
+  -p, --path string              path of the app (default ".")
+      --quit-on-fail             quit program if the app fails to start
+  -r, --reset-once               reset the app state once on init
+      --skip-proto               skip file generation from proto
+  -v, --verbose                  verbose output
+```
+
+**SEE ALSO**
+
+* [ignite testnet](#ignite-testnet)	 - Start a testnet local
+
+
 ## ignite version
 
 Print the current build information