Following up on Kusama runtime upgrade: referendum 301 is now up for a vote!

This proposal updates the Kusama Relay Chain and its Asset Hub and Bridge Hub with runtimes pulled from the Fellowship v1.0.0 release: make sure to vote at your earliest convenience! Note that the proposal has been submitted on the Whitelisted Caller track, meaning the Fellowship is also voting on a proposal no. 52 to whitelist the submission hash.

This proposal aims to execute with the same goal as referendum 297 was supposed to, but failed due to a call issue.

Voting NAY as warp-sync is not supported.

Warp-sync is an essential mechanism for integrity of the system by allowing validators to re-spin quickly. The release notes for this runtime mention that beefy is not yet compatible with warp-sync, therefore validators are expected to sync from scratch or use a snapshot service. But snapshot services are not reliable due to lack of funding from gov2. In fact, many voters mentioned the existence of warp sync as a reason for not funding snapshot services.

What happens when a validator restores storage from warp sync when beefy is active? Will they perform poorly? Will they be able to validate at all? There is no clarity in the release notes and on matrix on the matter.

Please, let's not ship features until they are ready. Warp sync should be an acceptance criteria.