Ungovernable wasm code keys

[grarco]

Seems like the wasm keys in storage do not fall under any address and therefore have no associated VP.

namada/crates/core/src/storage.rs

Lines 698 to 732 in 7d70e5a

	/// Returns a key of the wasm code of the given hash
	pub fn wasm_code(code_hash: &Hash) -> Self {
	let mut segments =
	Self::from(WASM_KEY_PREFIX.to_owned().to_db_key()).segments;
	segments.push(DbKeySeg::StringSeg(WASM_CODE_PREFIX.to_owned()));
	segments.push(DbKeySeg::StringSeg(code_hash.to_string()));
	Key { segments }
	}
	/// Returns a key of wasm code's hash of the given name
	pub fn wasm_code_name(code_name: String) -> Self {
	let mut segments =
	Self::from(WASM_KEY_PREFIX.to_owned().to_db_key()).segments;
	segments.push(DbKeySeg::StringSeg(WASM_CODE_NAME_PREFIX.to_owned()));
	segments.push(DbKeySeg::StringSeg(code_name));
	Key { segments }
	}
	/// Returns a key of the wasm code's length of the given hash
	pub fn wasm_code_len(code_hash: &Hash) -> Self {
	let mut segments =
	Self::from(WASM_KEY_PREFIX.to_owned().to_db_key()).segments;
	segments.push(DbKeySeg::StringSeg(WASM_CODE_LEN_PREFIX.to_owned()));
	segments.push(DbKeySeg::StringSeg(code_hash.to_string()));
	Key { segments }
	}
	/// Returns a key of the wasm code hash of the given code path
	pub fn wasm_hash(code_path: impl AsRef<str>) -> Self {
	let mut segments =
	Self::from(WASM_KEY_PREFIX.to_owned().to_db_key()).segments;
	segments.push(DbKeySeg::StringSeg(WASM_HASH_PREFIX.to_owned()));
	segments.push(DbKeySeg::StringSeg(code_path.as_ref().to_string()));
	Key { segments }
	}

Since we prevent modification to non-protected keys in storage, this means that no governance proposal can effectively modify these keys, which is required if we want to extend the allowlist for example.

We should place these keys under some VP to allow this and also add a check in this vp when a new wasm code is added to storage by running the validate_untrusted_wasm function to make sure that the tx doesn't contain unwanted features (this can be run by the community members before voting on the proposal but I believe a check in protocol would add more safety). On top of that we can also check that all the required keys are updated accordingly, e.g. if we add a new wasm code we should also insert the relative name, length and hash keys, and if we want to remove one from the allowlist we should do it in the way we designed (just remove from the allowlist and keep everything else for execution).

[grarco]

After #3100 we only need to update the parameters vp to check the correctness of the updates coming from a proposal

[cwgoes]

These checks are important in general, but not critical for phase 1 - we can take extra care for the first proposals.

[brentstone]

why reopened?

[grarco]

Second part of this issue hasn't been addressed yet. As per Chris's last comment we are leaving it for later