4

I am creating spec using ./polkadot build-spec --disable-default-bootnode --dev (I am running version 0.9.8-3a10ee63c-x86_64-linux-gnu)

spec generated using above command contains code field. My understanding is that this field contains wasm bytes. However, these bytes do not seem appropriate.

In a .wasm file, first 4 bytes are supposed to be magic number (\0asm here), next four bytes are supposed to be version of wasm spec, and probably some other pattern after that. I do not see those things in these wasm bytes.

Is it a bug? Does it use some encoding? Basically, how do I get wasm bytes from the spec?

I have posted JSON of spec here https://gist.github.com/kishansagathiya/b38b8f06964c8cb101ccab7fbefa428d

"code": "0x52bc537646db8e0528b52ffd0058543305de8806381552107855541d2c26fa78e0cf83b70a44352557cb13532c6d0da03c59cf642396cd44daa103555dc3770d003433894b7c7055d95101002568d5f5a28e71a5e6114909a47fa095fefffdbfb7ffde5bca2da54c01351574155015a0bfbfb2adf1efab2acd5757e1d...
Shawn Tabrizi
  • 12,206
  • 1
  • 38
  • 69
kishan sagathiya
  • 43
  • 4

1 Answers1

5

Wasm can be pretty hefty in its raw form. This leads to problems, for example, when upgrading from one version of the Substrate Runtime (the wasm file) to another. This is because the upgrade should fit into a block body which is capped at ≈4 MiB. A recent Polkadot wasm blob is 4.7 MiB. If you apply the zstd compression to the same file it would go down to 1.1 MiB.

That was a rationale for us to introduce compression for the wasm blobs. To distinguish between the compressed and uncompressed wasm, we introduced our own magic number. That's the magic you see there.

This logic is pretty much encapsulated in sp-maybe-compressed-blob crate.

pepyakin
  • 2,217
  • 19
  • 31