Common Expression Language (CEL)

[aaronc]

CEL is a small expression language based upon Protobuf from Google. It’s designed to be non-turing complete, side effect free and evaluate in linear time. It uses the protobuf type system, and looking through the docs it seems like we could mostly use it out of the box as even things like cost estimation have been considered.

The particular thing I have in mind is extending authz with user-defined Authorization conditions. For example, I want a SendAuthorization which checks a list of allowed recipients. We didn’t think of adding this when we created SendAuthorization so now I need to file an issue and hope it gets added in the next release. With a CEL-Authorization type we could just write this condition as msg.to_address in [‘cosmosxyz123456sdgj’, ‘cosmos35987135sdghaoeqwr’] and something similar could work for any Msg type because everything in CEL is protobuf-based.

One solution I’d thought of was supporting WASM Authorizations but WASM seems like a relatively heavyweight solution requiring a sandboxed VM, rust code, etc.

CEL looks pretty impressive so far with a robust golang implementation, and lots of nice features like optional type checking, fine-grained controls over available operations, a protobuf-based AST, etc.

Anyway, just wanted to share as this could be really useful for cases where all we really need is a lightweight expression language rather than full-on smart contract language.

[hxrts]

@sunnya97 @ValarDragon and @zmanian evaluated CEL recently. I believe osmosis opted not to use it, not sure about som.

[ValarDragon]

It wasn't a good fit for what were doing, because CEL is explicily stateless by design, whereas we needed something stateful.

[JimLarson]

That's not insurmountable if you use the functional evaluation results to modify state: {Actions, NewState} = F(Activity, State).

[ValarDragon]

Right, we started an approach along that design, and concluded that the API for our particular use case was going to be much more complex for end users than the alternative of defining some CosmWASM rust traits that a user can implement.

I think for the situation here, being stateless totally works, so CEL seems like a good fit for the goal. (I'm unclear as to the importance of the goal / if its value is worth the complexity)

[aaronc]

I've had an idea for a while of using a stateless language like to build simple somewhat "human readable" state machines using state charts. Since this has come up in a few contexts, I think I'll make a post about it soon.

[aaronc]

@ValarDragon I wonder if you'd be able to say a bit more about your use cases?

[zmanian]

the principal issue is that isn't a completely obvious way to introduce metering or gas to CEL implementations to prevent them from using too much compute.

It may be a dos vuln or just require forking the runtime.

[aaronc]

There is the estimate cost function which you could use to charge gas before execution. Unless you enable macros there's no looping - it should be almost constant time.

[zmanian]

Cool. I think this wasn't discovered in the previous evaluation.

[JimLarson]

I was co-developer of CEL for the last few years before I joined Agoric. Your use case sounds reasonable. I documented the compute overhead guarantees at https://github.com/google/cel-spec/blob/master/doc/langdef.md#performance

[aaronc]

Thanks for chiming in @JimLarson! And glad to have you as part of the Cosmos community now!

[aaronc]

Do you know if CEL is still being somewhat actively developed by google? There are a few things I'd like to suggest and wonder how responsive the CEL team might be to issues and PRs if we're considering it as a dependency.

[JimLarson]

It looks like there's been a dropoff in activities in the public Github repos google/cel-{cpp,go,spec}, but that could be due to a focus on development internal to Google. The team does prioritize responsiveness to external bug reports. Feature requests are taken seriously, but the team does not always have the bandwidth to implement them - contributions are welcome with some prior discussion for architectural alignment.

I'd suggest starting with a message to cel-go-discuss with your suggestions and go from there. Real suggestions from external users would be greatly appreciated even if you end up not using CEL.