How does AWM work in HyperSDK?

[mtgnoah]

I have been working on some AWM stuff today and I was wondering how HyperSDK uses every node as a relayer. Are all HyperSDK chains just outsourcing the sending and receiving logic to sender.go in AvalancheGo which is calling the Handle functions in warp_manager.go in HyperSDK?

[patrick-ogrady]

I have been working on some AWM stuff today and I was wondering how HyperSDK uses every node as a relayer.

Each node running a hypervm that supports AWM functionality (both validators and APIs) attempts to collect BLS signatures from all existing validators (over standard P2P) and make those signatures accessible over the standard hypersdk API:

• https://github.com/ava-labs/hypersdk/blob/main/vm/warp_manager.go

• hypersdk/rpc/jsonrpc_server.go

  Lines 129 to 196 in 37df80a

  	type GetWarpSignaturesReply struct {
  	Validators []*WarpValidator `json:"validators"`
  	Message *warp.UnsignedMessage `json:"message"`
  	Signatures []*chain.WarpSignature `json:"signatures"`
  	}
  	func (j *JSONRPCServer) GetWarpSignatures(
  	req *http.Request,
  	args *GetWarpSignaturesArgs,
  	reply *GetWarpSignaturesReply,
  	) error {
  	_, span := j.vm.Tracer().Start(req.Context(), "JSONRPCServer.GetWarpSignatures")
  	defer span.End()
  	message, err := j.vm.GetOutgoingWarpMessage(args.TxID)
  	if err != nil {
  	return err
  	}
  	if message == nil {
  	return ErrMessageMissing
  	}
  	signatures, err := j.vm.GetWarpSignatures(args.TxID)
  	if err != nil {
  	return err
  	}
  	// Ensure we only return valid signatures
  	validSignatures := []*chain.WarpSignature{}
  	warpValidators := []*WarpValidator{}
  	validators, publicKeys := j.vm.CurrentValidators(req.Context())
  	for _, sig := range signatures {
  	if _, ok := publicKeys[string(sig.PublicKey)]; !ok {
  	continue
  	}
  	validSignatures = append(validSignatures, sig)
  	}
  	for _, vdr := range validators {
  	wv := &WarpValidator{
  	NodeID: vdr.NodeID,
  	Weight: vdr.Weight,
  	}
  	if vdr.PublicKey != nil {
  	wv.PublicKey = bls.PublicKeyToBytes(vdr.PublicKey)
  	}
  	warpValidators = append(warpValidators, wv)
  	}
  	// Optimistically request that we gather signatures if we don't have all of them
  	if len(validSignatures) < len(publicKeys) {
  	j.vm.Logger().Info(
  	"fetching missing signatures",
  	zap.Stringer("txID", args.TxID),
  	zap.Int(
  	"previously collected",
  	len(signatures),
  	),
  	zap.Int("valid", len(validSignatures)),
  	zap.Int("current public key count", len(publicKeys)),
  	)
  	j.vm.GatherSignatures(context.TODO(), args.TxID, message.Bytes())
  	}
  	reply.Message = message
  	reply.Validators = warpValidators
  	reply.Signatures = validSignatures
  	return nil
  	}

Anyone can then fetch those signatures, turn them into a valid BLS Multi-Signature when they have signatures corresponding to sufficient stake, and issue the message on a destination. I wrote a test that performs an AWM transfer on each CI run (provides a good picture of how this works as an implementer): https://github.com/ava-labs/hypersdk/blob/37df80afb71ea85d853388b2d619376f309327f0/examples/tokenvm/tests/e2e/e2e_test.go#L564C1-L564C1. You can also see this in action in the demo I filmed here: https://twitter.com/_patrickogrady/status/1637850964072996864.

All that being said, none of the nodes act like a "true relayer" in the sense that they submit the message for you on the destination. In all implementations so far, that has been a user requirement (but could be implemented as a package for someone that wants to provide the utility with no changes to the hypersdk). To get around the problem of "no fees on destination", the TokenVM implements a "swap in" feature: https://twitter.com/_patrickogrady/status/1633021732868227075

---

Are all HyperSDK chains just outsourcing the sending and receiving logic to sender.go in AvalancheGo which is calling the Handle functions in warp_manager.go in HyperSDK?

AvalancheGo only provides functionality to sign a message with a node's BLS key (https://github.com/ava-labs/avalanchego/blob/master/proto/warp/message.proto), just so that you don't need to share your BLS private key with every Custom VM.

BLS Multi-Signature verification occurs using a client-side library that lives in the AvalancheGo codebase but not run in it during execution (imported by the hypersdk): https://github.com/ava-labs/avalanchego/tree/master/utils/crypto/bls

All other functionality (i.e. defining a message format, emitting messages for validators to sign [usually on block acceptance], fetching signatures from validators over P2P, making signatures available on the API, providing a min stake requirement for a message on a destination to be valid, defining AWM validation rules on the destination) are all provided in the background by the HyperSDK.