What is the state of middleware on v1.0.0-alpha?

[ethanfrey]

Summary

We are porting from 0.17.x to 1.0.0-alpha. After some adjustments the APIs look quite nice.
We disabled all middlewares at first to get things to compile, but now are looking to add those.
What is the current state and examples of middleware?

Additional details

It seems there is a Middleware trait but I cannot find any non-test examples.

We have a custom Deterministic middleware that just errors if any prohibited opcodes are found, which should be easy to port/test.

However, we will need an equivalent to the MeteringMiddleware from 0.17 and before that keeps track of gas usage and halts the contract on error. Is there any work towards such a middleware?

[matthew-a-thomas]

Subscribing for similar concerns.

I also wanted to volunteer my thoughts after looking at the FunctionMiddleware trait. Everyone please feel free to correct me if I'm wrong (I'm a Rust n00b). But it looks like metering has to be implemented in a "late" way, meaning your metering function can only be called after segments of operators. I don't see a way to implement it in an "early" way (call your metering function before segments of operators, like this) without compiling twice with two different middlewares and introducing quite a bit of chattiness and complexity between them.

It boils down to the lifetime parameters on Operator<'a> and on FunctionMiddleware::feed<'a>(...). Operators may not be cloned and saved for later analysis because of those lifetimes. So a middleware cannot cache or delay consumption of the operators (effectively a method of looking forward into the stream). All a middleware can do is consider the current operator in light of any metadata gleaned from previous operators.

I think it would be nice to be able to look forward in the stream of operators.

But does it really matter if metering is "late"? Sure their program will get to execute a few operators for "free" before you realize they're out of gas. The worst case would be a very large program without branching, just a very long stream of non-branching operators. But such a program will execute in constant time which isn't so expensive. And if it is expensive then just sprinkle in metering calls after every nth operator to place an upper limit on the number of "free" operators.

So maybe it doesn't matter in terms of metering. But not being able to look forward in the stream of operators might matter for other types of middleware. It's been a while since I studied automata theory but my instinct is it would enable more powerful middlewares.

[webmaster128]

There is a metering example now, showing how the Metering middleware is integrated. With #1941, this becomes more ahead-of-time compilation friendly. In CosmWasm/cosmwasm#668 the new metering middleware is integrated in a not-so-trivial use case, proving it works equally well using Singlepass and Cranelift. The only feature that is really missing is good error reporting, which is tracked here: #1931.

Given that, I think the core of this question is anwered and it can be followed up by much more specific tickets. Are you fine closing this, Ethan?

[ethanfrey]

Yes, it is working now. Happy to close this.