[Feature] new network.id opcode

[evan-schott]

Motivation

This PR introduces the opcode network.id to access the ID of the current network (ex: 0 for mainnet, or 3 for testnet3). This opcode can be used as a safeguard against replay attacks, as signatures or hashes of data can now be bound to a specific network. Users can now test program authorizations on testnet without worrying that the same authorizations be maliciously reused on mainnet.

Open questions

1. Should network.id be allowed in transition functions?
   • We could not think of any potential use cases of such a feature that could not just be modified to attesting to a network ID value (as a transition function input), and then passing that value to finalize to verify it is correct.
   • Additionally, @bendyarm has pointed out that including this may result in potential difficulties with resolving the compile time value of network.id as it could be obfuscated if it were involved in computation.
2. Should all block metadata be readily accessible? Relevant ARC

[evan-schott]

Should we add the network ID to the block-specific random seed?
https://github.com/AleoHQ/snarkVM/blob/69b5b17a9d7f32e4f3abbc562ef080adfb654877/synthesizer/program/src/logic/finalize_global_state/mod.rs#L57-L63

[d0cd]

Left some feedback and nits.
The main question we should answer is whether or not to allow network.id in a non-finalize context.

[d0cd]

Should we add the network ID to the block-specific random seed?

https://github.com/AleoHQ/snarkVM/blob/69b5b17a9d7f32e4f3abbc562ef080adfb654877/synthesizer/program/src/logic/finalize_global_state/mod.rs#L57-L63

It's not necessary for this PR, but could be a useful property. Networks with different IDs have different RNG state.