all: can avoid the use of bytes.Buffer and .Next simply by reslicing, since bytes.NewBuffer has an allocation and CPU time cost

[odeke-em]

Summary of Bug

Noticed throughout the repository that there is this pattern

sommelier/x/cork/keeper/keeper.go

Lines 103 to 108 in 3157d97

	keyPair := bytes.NewBuffer(iter.Key())
	keyPair.Next(1) // trim prefix byte
	blockHeight := sdk.BigEndianToUint64(keyPair.Next(8))
	id := keyPair.Next(32)
	val := sdk.ValAddress(keyPair.Next(20))
	contract := common.BytesToAddress(keyPair.Bytes())

Suggestion

Simply use byte slicing which can be made so much clearer and removes unnecessary expenses

		key := iter.Key()[1:]
		blockHeight, key := sdk.BigEndianToUint64(key[:8]), key[8:]
		id, key := key[:32], key[32:]
		val, key := sdk.ValAddress(key[:20]), key[20:]
		contract := common.BytesToAddress(key[:])

and you'll notice performance improvements from not being heavy handed with all these bytes.NewBuffer allocations

Other spots

sommelier/x/axelarcork/keeper/keeper.go

Lines 234 to 238 in 3157d97

	keyPair := bytes.NewBuffer(iter.Key())
	keyPair.Next(1) // trim prefix byte
	keyPair.Next(8) // trim chain ID
	blockHeight := binary.BigEndian.Uint64(keyPair.Next(8))
	contractAddress := common.BytesToAddress(keyPair.Next(20)) // contract

sommelier/x/axelarcork/keeper/keeper.go

Lines 154 to 160 in 3157d97

	keyPair := bytes.NewBuffer(iter.Key())
	keyPair.Next(1) // trim prefix byte
	keyPair.Next(8) // trim chain id, it was filtered in the prefix
	blockHeight := sdk.BigEndianToUint64(keyPair.Next(8))
	id := keyPair.Next(32)
	val := sdk.ValAddress(keyPair.Next(20))
	contract := common.BytesToAddress(keyPair.Next(20))

sommelier/x/axelarcork/keeper/keeper.go

Lines 335 to 337 in 3157d97

	keyPair := bytes.NewBuffer(iter.Key())
	keyPair.Next(1) // trim prefix byte
	id := keyPair.Next(32)

sommelier/x/axelarcork/keeper/keeper.go

Lines 535 to 537 in 3157d97

	keyPair := bytes.NewBuffer(iter.Key())
	keyPair.Next(1) // trim prefix byte
	chainID := sdk.BigEndianToUint64(keyPair.Next(8))