Properly allocate runtime IDs

[Yawning]

This is more of a policy decision than an actual coding one. For the sake of sanity, we should start properly allocating runtime IDs. Currently absolutely everything uses 0000000000000000000000000000000000000000000000000000000000000000 which is sub-optimal to the extreme.

I'm tempted to explicitly reject the default runtime ID value since that's what the uninitialized value will be on the Go side, but that might be overly disruptive, and it will be pointless if people just start using runtime ID 1 instead.

Things that need runtime IDs:

• runtime-ethereum
• simple-keyvalue
• keymanager

Note: It's not inconceivable that the same runtime will have multiple runtime IDs, since it doubles as a deployment identifier. Test runtimes that should never see production deployment should probably live in a dedicated part of the runtime ID space as well.

[kostko]

Is there a reason why the runtime ID is currently considered to be a public key? This doesn't seem right with the current design. Should we switch to something else just to make it clear? For example in roothash (and soon in storage, e.g., #1857) we use the namespace type (which has the exact same representation just without public key semantics).

[Yawning]

Is there a reason why the runtime ID is currently considered to be a public key?

No concrete reason. Was thinking we might want to allow runtime authors to sign things with the runtime signing key (as opposed to say, the SGX signing key) at some point, but I'm not sure that's needed. It likely depends on how updates are handled.

[kostko]

I think we should segment runtime identifiers as follows:

• The first byte of the runtime ID is reserved and can only be set to one of the predefined values. This is enforced by the consensus layer and other applications relying on runtime kinds.
• The first byte is interpreted as a bit vector, each bit specifying a flag. Bit 0 is the most significant bit.
• Bit 0 specifies whether the runtime is a test runtime (0 = production, 1 = test). Test runtimes are only allowed if a registry consensus parameter DebugAllowTestRuntimes is set. We could additionally only allow debug enclaves to be used with test runtimes.
• Bit 1 specifies whether the runtime is a key manager runtime (0 = not key manager, 1 = key manager). Only key manager runtime IDs are allowed to be used for the key manager runtime, enforced by the registry.
• Bit 2 specifies whether the runtime is a stateless runtime (0 = stateful, 1 = stateless).
• Bits 3-7 are reserved and must be set to zero.

Does this give us enough room for future extensions or do we need to reserve more than the first byte?

[Yawning]

Does the rest of the runtime ID need to have high entropy? Otherwise I'd say we can reserve more bits (first 32-64 bits), because we do have 256 bits to work with.

[kostko]

No, runtime IDs don't need high entropy IMO, so yeah I agree that reserving more makes sense here.

[Yawning]

Fixed by #2530