Polkadot Block Authorship has too much enshrined coordination logic: analysis.

The point of this write-up is to argue that the majority of the logic which determines the contents of the next Polkadot block should be expunged from the core protocol. The largest issue is that the protocol prescribes what the validators should do in sourcing work packages rather than describing the desired end result: a block containing reports of valid, or at least available work packages, each with an accompanying bond.

The random sorting of validators into groups to pre-validate work packages is just one of many approaches which may be used to deliver new block contents to the Polkadot network. It is unlikely to be the best of all possible approaches. Polkadot's core protocol should be altered to make the construction of new blocks a concern of the free market.

Let's compare the status quo[^1] to a hypothetical approach. In this alternative,
* any account with enough tokens can provide the security bond for work packages.
* the protocol provides no guidance on where the validator building a block ought to source its work packages.
* the block-authoring validator is nominally responsible for providing the full work packages to the rest of the network, rather than the validators assigned to a core. in practice, we assume that further protocols are layered on top of the core protocol for optimization.
* the notion of scheduled core assignments (outside of approval checking) would not exist.

All else should be equal, including the mechanisms for pre-scheduled coretime from Agile Coretime / CoreJAM. Space in a block may be reserved for certain authorized packages. This hypothetical specifically is concerned with making the protocol agnostic to the sourcing and bond of these packages, not with erasing the benefits of bulk scheduling.

**Benefits**:
1. The protocol is smaller, lowering barriers to specification and implementation
2. The protocol provides a touchpoint for block-building services to engage with validators with zero additional core protocol adaptations.
2a. This will lead to higher community developer engagement, as the entire "transaction supply chain" can be wholly implemented in third-party software.
2b. Outsourced block-building demonstrably leads to more economically efficient blocks.
3. The task of distributing chunks & data can be permissionlessly expanded beyond the validator set for increased scaling.

**Downsides**:
1. Centralization risk in block-building. If all validators hypothetically outsource their block-building functionality to the same entity, that entity gains some ability to censor transactions.
2. Validators engaging external services for block-building leak their identity to that block-builder slightly before BABE/SASSAFRAS would naturally reveal it.
3. High and bursty bandwidth utilization for block authors if they are the sole source of data for work packages in a block. Scaling practically depends on third-party solutions.

This category of approach is broadly referred to as Proposer-Builder separation and has been piloted in Ethereum to largely successful results, including high capital efficiency[^2]. Downside (1) has proved to be present in practice, though it has been mitigated by the social layer.

Downside (3) should be alleviated by better protocols for data distribution. One such approach would be smart propagation of full work packages through the p2p network prior to their corresponding reports being bundled into a block, and a gossip layer communicating which validators hold the data. This is in order to spread the load of distributing data across many nodes, not necessarily validators.

[^1]: In order for a work package to land on the chain, validators must: be assigned onto a core by some enshrined logic, receive a work package from collators, validate it, sign a message in effect putting down a bond against the package's security, distribute the package.

[^2]: off-chain searchers such as FlashBots have enabled Ethereum to be _more_ price-efficient than 2021 with half the TVL.