Merge avalanchego updates with snowman→chain renaming

Major changes:
- Renamed all 'snowman' references to 'chain' throughout codebase
- Renamed ENGINE_TYPE_SNOWMAN to ENGINE_TYPE_CHAIN
- Renamed ENGINE_TYPE_AVALANCHE to ENGINE_TYPE_DAG
- Updated all snow/* packages to chain/*
- Fixed package conflicts (avax → lux)
- Updated BLS cryptography API (SecretKey → Signer)
- Added L1 validator transaction methods
- Fixed Context vs ConsensusContext architectural changes
- Updated logging to use zap structured logging

Note: Build integration still in progress - chain consensus packages need further integration work

Author: hanzo-dev

api/info/service.go

@@ -13,8 +13,8 @@ import (
 	"go.uber.org/zap"
 
 	"github.com/luxfi/node/chains"
-	"github.com/luxfi/consensus/networking/benchlist"
-	"github.com/luxfi/consensus/validators"
+	"github.com/luxfi/node/chain/networking/benchlist"
+	"github.com/luxfi/node/chain/validators"
 	"github.com/luxfi/ids"
 	"github.com/luxfi/node/network"
 	"github.com/luxfi/node/network/peer"

api/server/mock_server.go

@@ -22,8 +22,8 @@ import (
 	"github.com/luxfi/ids"
 	"github.com/luxfi/log"
 	"github.com/luxfi/node/api"
-	"github.com/luxfi/consensus"
-	"github.com/luxfi/consensus/engine/core"
+	"github.com/luxfi/node/chain"
+	"github.com/luxfi/node/chain/engine/core"
 	"github.com/luxfi/node/utils/constants"
 	"github.com/luxfi/trace"
 )

api/server/server.go

@@ -11,8 +11,8 @@ import (
 
 	"github.com/stretchr/testify/require"
 
-	"github.com/luxfi/consensus"
-	"github.com/luxfi/consensus/consensustest"
+	"github.com/luxfi/node/chain"
+	"github.com/luxfi/node/chain/consensustest"
 )
 
 func TestRejectMiddleware(t *testing.T) {

api/server/server_test.go

@@ -0,0 +1,77 @@
+# Flow of a Single Blockchain
+
+```mermaid
+graph LR
+    A[P2P] --> B[Chain Router]
+    B --> C[Handler]
+    C --> D[Consensus Engine]
+    D --> E[Consensus]
+    D --> F[VM]
+    D --> G[DB]
+    D --> I[Sender]
+    F --> G
+    I --> A
+    I --> B 
+```
+
+## Intro
+
+The Avalanche primary network consists of 3 built-in blockchains: the X-Chain, C-Chain, and P-Chain. All three chains rely on the Snowman consensus protocol. The X-Chain, which previously used DAG-based Avalanche consensus, was upgraded to Snowman in the Cortina network update. 
+
+The X-Chain is used to manage assets. The C-Chain is used to create and interact with smart contracts. The P-Chain is used to coordinate validators and stake. At the time of writing, the Avalanche network has ~1200 validators. A set of validators makes up a subnet. Subnets can validate 1 or more chains. It is a common misconception that 1 subnet = 1 chain and this is shown by the primary subnet of Avalanche which is made up of the X-Chain, C-Chain, and P-Chain.
+
+A node in the Avalanche network can either be a validator or a non-validator. A validator stakes AVAX tokens and participates in consensus to earn rewards. A non-validator does not participate in consensus or have any AVAX staked but is used as a public API. Both validators and non-validator need to have their own copy of the chain and to know the current state of the mempool. At the time of writing, there are ~1200 validators and ~1800 non-validator.
+
+Each blockchain on Avalanche has several components: the virtual machine, database, consensus engine, sender, and handler. These components help the chain run smoothly. Blockchains also interact with the P2P layer and the chain router to send and receive messages.
+
+## P2P
+
+### [Outbound Messages](https://github.com/ava-labs/avalanchego/blob/master/message/outbound_msg_builder.go)
+
+The `OutboundMsgBuilder` interface specifies methods that build messages of type `OutboundMessage`. Nodes communicate to other nodes by sending `OutboundMessage` messages.
+
+All messaging functions in `OutboundMsgBuilder` can be categorized as follows:
+
+- **Handshake**
+  - Nodes need to be on a certain version before they can be accepted into the network.
+- **State Sync**
+  - A new node can ask other nodes for the current state of the network. It only syncs the required state for a specific block.
+- **Bootstrapping**
+  - Nodes can ask other nodes for blocks to build their own copy of the chain. A node can fetch all blocks from the locally last accepted block to the current last accepted block in the network.
+- **Consensus**
+  - Once a node is up to tip they can participate in consensus! During consensus, a node conducts a poll to several different small random samples of the validator set. They can communicate decisions on whether or not they have accepted/rejected a block.
+- **App**
+  - VMs communicate application-specific messages to other nodes through app messages. A common example is mempool gossiping.
+
+Currently, Avalanchego implements its own message serialization to communicate. In the future, Avalanchego will use protocol buffers to communicate.
+
+### [Network](../network/network.go)
+
+The networking interface is shared across all chains. It implements functions from the `ExternalSender` interface. The two functions it implements are `Send` and `Gossip`. `Send` sends a message of type `OutboundMessage` to a specific set of nodes (specified by an array of `NodeIDs`). `Gossip` sends a message of type `OutboundMessage` to a random group of nodes in a subnet (can be a validator or a non-validator). Gossiping is used to push transactions across the network. The networking protocol uses TLS to pass messages between peers.
+
+Along with sending and gossiping, the networking library is also responsible for making connections and maintaining connections. Any node whether they are a validator or non-validator will attempt to connect to the primary network.
+
+## [Router](./networking/router/chain_router.go)
+
+The `ChainRouter` routes all incoming messages to its respective blockchain using `ChainID`. It does this by pushing all the messages onto the respective Chain handler’s queue. The `ChainRouter` references all existing chains on the network such as the X-chain, C-chain, P-chain and possibly any other chain. The `ChainRouter` handles timeouts as well. When sending messages on the P2P layer, timeouts are registered on the sender and cleared on the `ChainRouter` side when a response is received. If no response is received, then we trigger a timeout. Because we handle timeouts on the `ChainRouter` side, the handler is reliable. Peers not responding means timeouts trigger and the `ChainRouter` will still notify the handler of failure cases. The timeout manager within `ChainRouter` is also adaptive. If the network is experiencing long latencies, timeouts will then be adjusted as well.
+
+## [Handler](./networking/handler/handler.go)
+
+The main function of the `Handler` is to pass messages from the network to the consensus engine. It receives these messages from the `ChainRouter`. It passes messages by pushing them onto a sync or async queue (depends on message type). Messages are then popped from the queue, parsed, and routed to the correct function in consensus engine. This can be one of the following.
+
+- **State sync message (sync queue)**
+- **Bootstrapping message (sync queue)**
+- **Consensus message (sync queue)**
+- **App message (async queue)**
+
+## [Sender](./networking/sender/sender.go)
+
+The main role of the `sender` is to build and send outbound messages. It is actually a very thin wrapper around the normal networking code. The main difference here is that sender registers timeouts and tells the [router] to expect a response message. The timer starts on the sender side. If there is no response, sender will send a failed response to the [router]. If a node is repeatedly unresponsive, that node will get benched and sender will immediately start marking those messages as failed. If a sufficient amount of network deems the node benched, it might not get rewards (as a validator).
+
+## [Consensus Engine](./consensus/snowman/consensus.go)
+
+Consensus is defined as getting a group of distributed systems to agree on an outcome. In the case of the Avalanche network, consensus is achieved when validators are in agreement with the state of the blockchain. The novel consensus algorithm is documented in the [white paper](https://assets.website-files.com/5d80307810123f5ffbb34d6e/6009805681b416f34dcae012_Avalanche%20Consensus%20Whitepaper.pdf). There are two main consensus algorithms: Avalanche and Snowman. The engine is responsible for proposing a new block to consensus, repeatedly polling the network for decisions (accept/reject), and communicating that decision to the `Sender`.
+
+## [Blockchain Creation](../chains/manager.go)
+
+The `Manager` is what kickstarts everything in regards to blockchain creation, starting with the P-Chain. Once the P-Chain finishes bootstrapping, it will kickstart C-Chain and X-Chain and any other chain. The `Manager`’s job is not done yet, if a create chain transaction is seen by a validator, a whole new process to create a chain will be started by the `Manager`. This can happen dynamically, long after the original 3 chains are created and bootstrapped.

chain/README.md

@@ -0,0 +1,130 @@
+// Copyright (C) 2019-2025, Ava Labs, Inc. All rights reserved.
+// See the file LICENSE for licensing terms.
+
+package snow
+
+import (
+	"fmt"
+	"sync"
+
+	"go.uber.org/zap"
+
+	"github.com/luxfi/ids"
+	"github.com/luxfi/node/utils/logging"
+)
+
+var (
+	_ Acceptor = acceptorWrapper{}
+
+	_ AcceptorGroup = (*acceptorGroup)(nil)
+)
+
+// Acceptor is implemented when a struct is monitoring if a message is accepted
+type Acceptor interface {
+	// Accept must be called before [containerID] is committed to the VM as
+	// accepted.
+	//
+	// If the returned error is non-nil, the chain associated with [ctx] should
+	// shut down and not commit [container] or any other container to its
+	// database as accepted.
+	Accept(ctx *ConsensusContext, containerID ids.ID, container []byte) error
+}
+
+type acceptorWrapper struct {
+	Acceptor
+
+	// If true and Accept returns an error, the chain this callback corresponds
+	// to will stop.
+	dieOnError bool
+}
+
+type AcceptorGroup interface {
+	// Calling Accept() calls all of the registered acceptors for the relevant
+	// chain.
+	Acceptor
+
+	// RegisterAcceptor causes [acceptor] to be called every time an operation
+	// is accepted on chain [chainID].
+	// If [dieOnError], chain [chainID] stops if Accept returns a non-nil error.
+	RegisterAcceptor(chainID ids.ID, acceptorName string, acceptor Acceptor, dieOnError bool) error
+
+	// DeregisterAcceptor removes an acceptor from the group.
+	DeregisterAcceptor(chainID ids.ID, acceptorName string) error
+}
+
+type acceptorGroup struct {
+	log logging.Logger
+
+	lock sync.RWMutex
+	// Chain ID --> Acceptor Name --> Acceptor
+	acceptors map[ids.ID]map[string]acceptorWrapper
+}
+
+func NewAcceptorGroup(log logging.Logger) AcceptorGroup {
+	return &acceptorGroup{
+		log:       log,
+		acceptors: make(map[ids.ID]map[string]acceptorWrapper),
+	}
+}
+
+func (a *acceptorGroup) Accept(ctx *ConsensusContext, containerID ids.ID, container []byte) error {
+	a.lock.RLock()
+	defer a.lock.RUnlock()
+
+	for acceptorName, acceptor := range a.acceptors[ctx.ChainID] {
+		if err := acceptor.Accept(ctx, containerID, container); err != nil {
+			a.log.Error("failed accepting container",
+				zap.String("acceptorName", acceptorName),
+				zap.Stringer("chainID", ctx.ChainID),
+				zap.Stringer("containerID", containerID),
+				zap.Error(err),
+			)
+			if acceptor.dieOnError {
+				return fmt.Errorf("acceptor %s on chain %s erred while accepting %s: %w", acceptorName, ctx.ChainID, containerID, err)
+			}
+		}
+	}
+	return nil
+}
+
+func (a *acceptorGroup) RegisterAcceptor(chainID ids.ID, acceptorName string, acceptor Acceptor, dieOnError bool) error {
+	a.lock.Lock()
+	defer a.lock.Unlock()
+
+	acceptors, exist := a.acceptors[chainID]
+	if !exist {
+		acceptors = make(map[string]acceptorWrapper)
+		a.acceptors[chainID] = acceptors
+	}
+
+	if _, ok := acceptors[acceptorName]; ok {
+		return fmt.Errorf("callback %s already exists on chain %s", acceptorName, chainID)
+	}
+
+	acceptors[acceptorName] = acceptorWrapper{
+		Acceptor:   acceptor,
+		dieOnError: dieOnError,
+	}
+	return nil
+}
+
+func (a *acceptorGroup) DeregisterAcceptor(chainID ids.ID, acceptorName string) error {
+	a.lock.Lock()
+	defer a.lock.Unlock()
+
+	acceptors, exist := a.acceptors[chainID]
+	if !exist {
+		return fmt.Errorf("chain %s has no callbacks", chainID)
+	}
+
+	if _, ok := acceptors[acceptorName]; !ok {
+		return fmt.Errorf("callback %s does not exist on chain %s", acceptorName, chainID)
+	}
+
+	if len(acceptors) == 1 {
+		delete(a.acceptors, chainID)
+	} else {
+		delete(acceptors, acceptorName)
+	}
+	return nil
+}

chain/acceptor.go

@@ -0,0 +1,46 @@
+// Copyright (C) 2019-2025, Ava Labs, Inc. All rights reserved.
+// See the file LICENSE for licensing terms.
+
+package choices
+
+import (
+	"context"
+
+	"github.com/luxfi/ids"
+)
+
+// Decidable represents element that can be decided.
+//
+// Decidable objects are typically thought of as either transactions, blocks, or
+// vertices.
+type Decidable interface {
+	// ID returns a unique ID for this element.
+	//
+	// Typically, this is implemented by using a cryptographic hash of a
+	// binary representation of this element. An element should return the same
+	// IDs upon repeated calls.
+	ID() ids.ID
+
+	// Accept this element.
+	//
+	// This element will be accepted by every correct node in the network.
+	// All subsequent Status calls return Accepted.
+	Accept(context.Context) error
+
+	// Reject this element.
+	//
+	// This element will not be accepted by any correct node in the network.
+	// All subsequent Status calls return Rejected.
+	Reject(context.Context) error
+
+	// Status returns this element's current status.
+	//
+	// If Accept has been called on an element with this ID, Accepted should be
+	// returned. Similarly, if Reject has been called on an element with this
+	// ID, Rejected should be returned. If the contents of this element are
+	// unknown, then Unknown should be returned. Otherwise, Processing should be
+	// returned.
+	//
+	// TODO: Consider allowing Status to return an error.
+	Status() Status
+}