Packet Spec: Hash App data rather than standardizing encoding

[AdityaSripal]

The following is the Packet spec that uses only hashing rather than the cbor encoding in the previous spec. This is meant to allow reviewers to compare the two options.

Benefits:

• No standardized encoding allows implementation by virtually any platform with low maintanence burden
• Canonical by construction

Cons:

• Must specify a unique commitment scheme for the internal packet data and acknowledgement rather than relying on existing encoding
• Multiple hashes might be slow and expensive in certain environments (e.g. EVM, and ZKVM)

[sangier]

Dropping some thoughts about the cons: "Multiple hashes might be slow and expensive in certain environments (e.g. EVM, and ZKVM)"

• Checking the ethereum yellow paper I noticed that a simple transfer cost 21,000 gas, while a keccak256 encoding only costs 30 gas for the first 32 bytes, and 6 gas for each additional 32 bytes. Thus at least for EVM environment multiple hashes are not expensive and should be fast as keccack is the native enconding function.
• The multiple hashes may affect the zkvm proof generation and verification processes, but I'm not sure how.
• The native encoding function for Solana is sha-256.
• Cairo uses natively Poseidon and Pedersen which are zk-snark friendly.

So, intra-platform (e.g. Cosmos to Cosmos, EVM to EVM, Sol to Sol ...) we could use the native hashing functions being fast and cheap. However inter-platform (e.g EVM to Solana..) we must use one hashing function and use it in both the environments, which may affect the computation of one of the side.

[sangier]

Suggested change

	buffer = append(buffer, sha256.hash(data))
	buffer = append(buffer, sha256.hash(packet.data))