Dmytro Kozhevin

> We could replace "invoking unknown export" with "invoking unknown function, the following functions are available: ". Yeah, this message is technically correct (because it's possible to e.g. export a...

> 2: [Failed Diagnostic Event (not emitted)] **contract:CAKX2ZMAKMID6PEDSUHBMU4NAHWUIEFXTXHESCSN7IRVG5E4QKAWSGLU**, topics:[error, Error(WasmVm, MissingValue)], data:["invoking unknown export", **balance**] Actually the necessary pieces are already there (both contract address and the function name), so...

This should has been addressed a while ago, currently the error looks like this: ``` Event log (newest first): 0: [Diagnostic Event] contract:CAFE4Z45OPZ3IC3XLPEOCMJPEYTUAD4VID2ZZ45IT34BRFNMHNIM65TN, topics:[error, Error(WasmVm, MissingValue)], data:["trying to invoke non-existent...

> we should document how to build a "reference min-spec node" that can be used to run those benchmarks. I That's a good idea, but I'm not sure which spec...

> but I am pretty sure you need to call the put host function (how entries end up in the "modified" list) Nope, currently we actually overwrite all the RW...

> generate_type_conversion_error(got_val, expected_type, argname) -> ! or something. That's kind of nice, but we still would need to embed this in a lot of places, as every function would need...

> The validation could only apply to new contracts deployed with an env-meta version matching a newer protocol? Yeah, that's an option as well, though the existing contracts would need...

> The thing I like about using specs is that only helps with inputs to a contract, and outputs, but a host fn could be inserted into lots of places,...

> It's defintely a problem folks have run into. Sure, but the key point here is that the logic still belongs to your contract, and that it's easy to catch...

`is_valid_function_call` approach above is really pretty much what I suggested above for using the contract spec instead of the additional contract function (contracts already expose all the type information in...