[DRAFT] SMA 1: Append initial validation data to bytecode

[Zer0dot]

Motivation

The goal is to create a semi-modular account which would enable much cheaper deployments at a larger scale. To achieve this, a few options should be explored.

1. Append initial validation data, meant to be used with a specifically tailored (stateless? purpose-built?) validation, then fallback to that validation in cases where a validation is missing.

2. Add immutable validation data to account implementations for relevant validations-- potentially streamlining a pipeline to deploy more implementations with different immutable validations.

3. Hardcode specific validation behaviour into the account, this could be the most efficient, but it may result in fragmentation of account implementations, so I would only explore this option if we are certain we would only need one or two different variants, and the loss in flexibility is worth it.

Solution

This PR, although the branch is vaguely named (sorry) tackles the first option. We append a validation and its relevant, arbitrarily encoded data (which it will then decode according to its own schema) to the proxy bytecode upon deployment.

This allows us to skip the initialization phase entirely, and results in significant gas savings on deployment, but increased gas in cases where the fallback validation should be used.

The reasoning behind using abi.encodePacked() for appended bytecode rather than a standard abi-encoded byte array is that, since this is an immutable validation, only that specific validation needs access to this data, so we don't lose any flexibility by requiring that the data be encoded according to that validation's decoding scheme.

In other words, because the relevant validation knows the parameters it needs, we can safely abi.encodePacked those parameters in most cases. Validations can still require that appended data be encoded using normal abi-encoding, though, as complex dynamic types would result in complex decoding schemes.