Cleanup Smart contracts around execution parameters

[janezpodhostnik]

Problem Definition

PR #6891 moves the metering settings from the service account to a separate account.
But we also need to clean up some things:

• The new account should have a minimal wrapper contract so that there is a nice way (for users) to read the metering settings. This wrapper contract should be part of the flow-core-contract repo and of the bootstrapping. The contract should also provide an admin resource that can change the weights, that would be given to the service account.

• A change to the SystemAccountContract so that it forwards calls to get the weights to the new account, so that any current user code referencing that does not need to change.

• The bootstrapping should deploy the metering settings (and the contract) to a separate account. (one of the existing ones can be used, but not one that changes on ever block)

• Remove the public flow receiver from the new account, because it does not need one.

[joshuahannan]

For the new contract, in addition to the getters for the metering settings, we also need a way to set those from the service account contract, right?

[janezpodhostnik]

Yes. Ill add that to the issue.

[joshuahannan]

Actually, why not just put these parameters in the smart contract instead of storage? That way, they wouldn't be able to be updated by just a regular transaction from the new account and we could restrict it to a resource that is owned by the service account

[janezpodhostnik]

The problem with that is that when the FVM would need to read the it would also need to use a script. Which would drastically increase the amount of registers touched.

Keep in mind that this is a temporary solution and should go away in less than a year.

[joshuahannan]

okay, that makes sense. If it is just temporary, then we should probably just make it as simple as possible. Just a smart contract that can query these values, then if we need to change them, we can just sign a transaction with this account that stores them. No need to make it complicated and add a service account multisig in there too.

Have you already started on the smart contract? I can make the PR in the core contracts repo if you haven't started yet

[janezpodhostnik]

Thank you very much.
I have not started yet.

I had this locally when I was testing:

access(all) contract FlowExecutionParameters {
				
					// Gets Execution Effort Weights from the service account's storage
					access(all) view fun getExecutionEffortWeights(): {UInt64: UInt64} {
						return self.account.storage.copy<{UInt64: UInt64}>(from: /storage/executionEffortWeights)
							?? panic("execution effort weights not set yet")
					}
				
					// Gets Execution Memory Weights from the service account's storage
					access(all) view fun getExecutionMemoryWeights(): {UInt64: UInt64} {
						return self.account.storage.copy<{UInt64: UInt64}>(from: /storage/executionMemoryWeights)
							?? panic("execution memory weights not set yet")
					}
				
					// Gets Execution Memory Limit from the service account's storage
					access(all) view fun getExecutionMemoryLimit(): UInt64 {
						return self.account.storage.copy<UInt64>(from: /storage/executionMemoryLimit)
							?? panic("execution memory limit not set yet")
					}
				
					init() {
					}
				}