## Project Description: Polkadot Containers

Background (Kernel/Userland): https://hackmd.io/uncbykXKTX2h8xde-zGNWw .

I have the underlying goal to decouple Polkadot core utilization from the advancement of chains.

Cores effectively provide two resources: data and computation. Both are secure under a standard blockchain crypto-economic model.

To address data, we have created https://github.com/thrumdev/blobs as a data availability interface which will, in the future, scale to an arbitrary number of cores.

To address computation, We could define **Containers**.

A container is something which Polkadot interprets as a parachain, but which is actually (near) **stateless**: there is no requirement that any block have anything to do with any prior block, and authorization information is drawn from the PoV itself.

For example, containers could encapsulate EVM or Wasm smart contracts.

Instances of containers can be deployed on multiple cores in order to process many workloads in parallel.

We'd build a **Container SDK** for building and deploying Containers and container nodes.

A Container is a simple wrapper around a pluggable `fn authorize` and `fn execute`.

/// generic payload in, head-data and extra data (stored by re-executing nodes) out.
fn execute(payload: Vec<u8>) -> (HeadData, Vec<u8>);

type RelayParentInfo = (Hash, BlockNumber, StateRoot);
fn authorize(relay_parent: RelayParentInfo, auth_data: Vec<u8>, payload: Vec<u8>) 
    -> bool; 

The Container `PoV` is a simple concatenation of the `auth_data` and `payload`.
For example, an EVM container might be authorized by some known authority set which is referenceable elsewhere on the relay chain, but it simply interprets the payload as a batch of EVM transactions to execute against some state root. In this case, the auth data would be a proof of the external authority set against the relay parent, plus a signature.

The Container SDK should make it extremely easy to write containers, and should introduce a node as a library which is capable of submitting collations to Polkadot for any number of registered containers. Except for the Container entrypoints, the Container SDK will not be a framework but rather a collection of libraries.

We should also submit an RFC to elide deposits on Polkadot for parachains which have the same code as others, provided that the code is locked. Each container instance should have deposits only for the head-data.

Goals:
* It should be simple to prove to an external state machine (e.g. bridged ethereum smart contract, parachain) that a container executed a work item with a particular result
* Serve existing optimistic rollups
* Serve other DA layers
* Scale to an arbitrary number of cores

Applications:
* Parallel execution of transactions in a serializable execution model
* e.g. sequenced on `blobs`
* Cluster Orchestration: auto-scaling, deploying, scheduling work on clusters of containers