I suggested the need for something along these lines a while ago. But IMO this should be treated as an escape hatch, not as “the solution”.
The reason is simple: we still need precompiles with stable APIs for mission-critical functionality. If the main integration path is “dispatch arbitrary SCALE-encoded runtime calls”, you can’t reliably build/combine higher-level abstractions on top, because runtime upgrades can subtly change pallet call layouts/semantics and break contracts. Therefore, that implies either ossifying some less than ideal pallets that can’t upgrade, or not having proper composability.
@ultracoconut I’m struggling to take the proposal seriously enough to invest time reviewing it in depth, mainly because it doesn’t seem to benchmark itself against the tradeoffs of the solutions that already exist (as @sodazone pointed out). Without that comparison, it’s hard to evaluate what we gain and what we lose.
Also, some parts read internally inconsistent. For example:
- You say the precompile verifies an H160 signature and then links that H160 to an AccountId32. Even granting that approach (similar to what pallet-revive does, with its own tradeoffs, which is far from a silver-bullet solution),
- then you say the runtime constructs a new SIGNED extrinsic, signed again with a “runtime-controlled proxy key”.
If the signature has already been verified, why is there a second signing step at all? Why not treat this as an already-checked payload (e.g., a CheckedExtrinsic) and dispatch directly?
Related: what exactly does “runtime-controlled proxy key” mean here? Where is that key material stored, what are the security assumptions, and how does this avoid becoming a privileged signer/origin?
Stepping back, it’s hard for me to take this seriously right now because the whole thing feels too shallow and, in places, frankly nonsensical.