Okay, that was expected anyway. Not an urgent concern because, well, how many validators are running Kagome implementation right now? But may become a concern in the future for the aforementioned reasons. I’d have an eye on it.
Validators are never going to run Kagome if they can possibly be slashed for doing it, and they can possibly be slashed for it because of the lack of determinism, and the lack of determinism isn’t fixed because validators aren’t running Kagome anyway.
It’s a snake biting its tail.
2 Likes
All the things you have written about wasmtime versioning or implementing a custom wasm vm do not really indicate that it is expected. All of this is indicating that there should be one implementation to prevent indetermenism between different implementations. Which would make everything we are worked on useless as @tomaka already said.
We need to start defining an environment to run validation in that isn’t bound to special implementations, at least for the general vm. For stuff like stack depth metering we need to implement a way that is implementation agnostic and can be implemented by everybody. The same applies to all the other problems. For sure we will hit hidden bugs that will lead to slashes, but we can revert these slashes, learn and ensure that it never happens again.
That was expected because we don’t enforce a concrete VM implementation in our spec right now, so different implementations would have emerged sooner or later. That happened sooner. Okay, now we should deal with it somehow.
I still insist it’s not technically possible. If you see how to implement it, please tell me. I mean, implementation-agnostic native stack metering is not rocket science, but implementation-agnostic stack usage by different implementations is science fiction, as far as I can tell. And without deterministic usage, deterministic metering makes no sense.
I just had another idea. First we should get a complete list of indeterminisms, then we might be able to extend the time dispute mechanism for other cases as well:
3 Likes
Ty! In generally something that could be worked/tried out as part of: https://polkadot.polkassembly.io/post/1683
1 Like
Around this, we’ve discussed rerunning PVF builds whenever wasmtime changes:
It bring up one question:
Anytime a parachain updates its PVF then all validators build he PVF and vote upon the result. We do not attempt further optimization here because they’ll all build the PVF eventually anyways.
Can we similarly assume that “most” wasmtime updates require every validator to rebuild every PVF?
Nobody has yet explained what was the problem with the existing stack metering, which I’ve linked twice already.
If we track the logical stack usage in a deterministic way, and assume that wasmtime (and other Wasm implementations) are implemented in a way that there exists a k such that native_stack <= k * logical_stack, then the problem is solved.
We would only have to determine this k, and I don’t see why we couldn’t set k to an absurdly high value like for example 1024.
1 Like
I had a similar thought today. Is there such a k - I think there should be, if so I agree that the problem seems solved.
@dmitry.sinyavin can you get in touch with them to build up how that conformance testing should actually look like. I think we need to become more concrete. E.g. what exactly is the spec we are testing conformance to and how?
Perhaps related:
Well, I kinda tried to explain that… There’s no spoon k. That’s what was assumed from the very start, that there’s some proportion here, and we can rely on it, and I was assigned to check that assumption. Unfortunately, it’s just wrong. You can produce a function that uses close to zero WASM value stack and creates a huge native stack frame, and vice-versa, you can compile a WASM bytecode utilizing a lot of value stack depth into native code that doesn’t create a stack frame at all. Moreover, that behavior (concrete stack sizes) deviates between different environment versions and differs dramatically between different environments. So even if k existed, it would be useless as we assume the possibility of using different environments and each one’s compilation logic is different.