Technical design: Assembling Wasm bytecode

[raulk]

The Filecoin network has several limits at different layers that hinder the installation of typical statically-linked Wasm code in a single message:

• Mpool limit: 64KiB per message
• Gossipsub limit: 1MiB per message
• Bitswap limit: 2MiB per message
• libp2p limit: 4MiB per message
• Params limit for internal and chain messages: (?, if any)

Possible solutions:

• ⛔ Hard limit of (less than) 64KiB of code. No-go because this would severely cripple the utility of FVM.
• ⛔ Extend limits generally. No-go because it creates new attack vectors.
• ⛔ Conditional limits. No-go: impractical and leaky.
• ✅ 2 phase installation (preferred solution)
  • Deploy/Bootstrap/Bootloader actors that accumulate/append segments of bytecode in state.
  • Once complete, they call the InitActor#InstallCode method with the final bytecode and self-destruct.
  • They are user-land so that logic is customizable (e.g. compression, patching, etc.) This allows users to find their own ways to reduce their on-chain footprint.
  • All logic happens in actor code, thus it pays for gas, thus disarming any potential bombs.
  • Need to introduce an InitActor#GetCode(cid) method (or equivalent syscall) to fetch existing code to enable advanced use cases. Equivalent to Ethereum’s EXTCODECOPY.
  • Supports permissioned installation and upgrades, similar to [Solana Buffers](https://docs.solana.com/cli/deploy-a-program#using-an-intermediary-buffer-account).