Remove Stale References of the toEngine Channel (#4101)

Author: samliok

chains/linearizable_vm.go

@@ -67,8 +67,7 @@ func (vm *initializeOnLinearizeVM) Linearize(ctx context.Context, stopVertexID i
 }
 
 // linearizeOnInitializeVM transforms the proposervm's call to Initialize into a
-// call to Linearize. This enables the proposervm to provide its toEngine
-// channel to the VM that is being linearized.
+// call to Linearize.
 type linearizeOnInitializeVM struct {
 	vertex.LinearizableVMWithEngine
 	stopVertexID ids.ID

snow/engine/common/vm.go

@@ -42,7 +42,6 @@ type VM interface {
 	//                 system, `genesisBytes` would probably contain a genesis
 	//                 transaction that gives coins to some accounts, and this
 	//                 transaction would be in the genesis block.
-	// [toEngine]: The channel used to send messages to the consensus engine.
 	// [fxs]: Feature extensions that attach to this VM.
 	Initialize(
 		ctx context.Context,

vms/README.md

@@ -30,7 +30,7 @@ The Snowman VM needs to implement the following functions used by the consensus
 
 Build block allows the VM to propose a new block to be added to consensus.
 
-The VM can send messages to the consensus engine through a `toEngine` channel that is passed in when the VM is initialized. This channel allows the VM to send the consensus engine a message when it is ready to build a block. For example, if the VM receives some transactions via gossip or from an API, then it will signal that it is ready to build a block by sending a `PendingTxs` message to the consensus engine. The PendingTxs message signals to the consensus engine that it should call `BuildBlock()` so that the block can be added to consensus.
+The VM gets notified of when to build a block after `vm.WaitForEvent()` returns with a `PendingTxs` message.
 
 The major caveat to this is the Snowman VMs are wrapped with [Snowman++](./proposervm/README.md). Snowman++ provides congestion control by using a soft leader, where a leader is designated as the proposer that should create a block at a given time. Snowman++ gracefully falls back to increase the number of validators that are allowed to propose a block to handle the case that the leader does not propose a block in a timely manner.
 
@@ -113,7 +113,7 @@ Therefore, if the tree of blocks in consensus (with root L, the last accepted bl
  A     B
  |    / \
  C   D   G
-    / \ 
+    / \
    E   F
 ```
 

vms/platformvm/block/executor/rejector.go

@@ -6,7 +6,6 @@ package executor
 import (
 	"go.uber.org/zap"
 
-	"github.com/ava-labs/avalanchego/snow/engine/common"
 	"github.com/ava-labs/avalanchego/vms/platformvm/block"
 )
 
@@ -17,7 +16,6 @@ var _ block.Visitor = (*rejector)(nil)
 // being shutdown.
 type rejector struct {
 	*backend
-	toEngine        chan<- common.Message
 	addTxsToMempool bool
 }
 
@@ -88,10 +86,5 @@ func (r *rejector) rejectBlock(b block.Block, blockType string) error {
 		return nil
 	}
 
-	select {
-	case r.toEngine <- common.PendingTxs:
-	default:
-	}
-
 	return nil
 }

vms/proposervm/vm_test.go

@@ -2828,10 +2828,7 @@ func TestBootstrappingAheadOfPChainBuildBlockRegression(t *testing.T) {
 		return innerBlock3, nil
 	}
 
-	// Attempting to build a block now errors with an unexpected error. This
-	// results in dropping the build block request, which breaks the invariant
-	// that BuildBlock will be called at least once after sending a PendingTxs
-	// message on the ToEngine channel.
+	// Attempting to build a block now errors with an unexpected error.
 	_, err = proVM.BuildBlock(context.Background())
 	require.NoError(err)
 }