You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
When we executing Substrate Runtime we assume that the runtime is always trusted. That is, each call to the runtime API finishes in some reasonable amount of time (definitely finite). The Substrate Runtime authors and the governance of chains are supposed to ensure this property. It's in their interests to uphold this property lest they brick the chain.
After talking to @tomaka and @bkchr I found out that there are cases when we may actually limit the amount of time spent in executing Substrate Runtime for preventing abusing it by the RPC or other requests from untrusted sources.
This is why we may want to consider supporting for metering the execution of the runtime in a similar fashion to how contracts are limited by gas metering. We may be able to reuse the same machinery for instrumentation of the runtime code. However, in the case of wasmtime we should consider using their fuel mechanism or interrupts since those (especially the latter) seem to be more efficient compared to wasm-utils/wasm-instrument instrumentation. Wasmi atm does not have a native analogue unfortunately .
The text was updated successfully, but these errors were encountered:
When we executing Substrate Runtime we assume that the runtime is always trusted. That is, each call to the runtime API finishes in some reasonable amount of time (definitely finite). The Substrate Runtime authors and the governance of chains are supposed to ensure this property. It's in their interests to uphold this property lest they brick the chain.
After talking to @tomaka and @bkchr I found out that there are cases when we may actually limit the amount of time spent in executing Substrate Runtime for preventing abusing it by the RPC or other requests from untrusted sources.
This is why we may want to consider supporting for metering the execution of the runtime in a similar fashion to how contracts are limited by gas metering. We may be able to reuse the same machinery for instrumentation of the runtime code. However, in the case of wasmtime we should consider using their fuel mechanism or interrupts since those (especially the latter) seem to be more efficient compared to wasm-utils/wasm-instrument instrumentation. Wasmi atm does not have a native analogue unfortunately .
The text was updated successfully, but these errors were encountered: