Announcing PolkaVM - a new RISC-V based VM for smart contracts (and possibly more!)

Tech Talk
,
68

I expect that ink! will be adding a CorePlay backend and some abstractions to deal with the concurrency. The execution environments of pallet_contracts and CorePlay are similar enough. If you think about it: CorePlay is strictly more powerful than pallet_contracts. i.e pallet_contracts is a special case of CorePlay: All interactions fit into one block. CorePlay will support uninterrupted execution via its call entry point.

Ideally, you will be able to recompile your ink! program to run on CorePlay without any changes. However, to make use of multi block execution you will need to add a few things.

Meaning: Every ink! program is a (crippled) CorePlay program but not vice versa.

  1. I can’t comment on any timelines.

  2. There is no priorization to be done. Completely different teams. Nothing much changes about contracts except its VM. Hence it is a much smaller endeavour than CorePlay where everything changes and the change to PolkaVM is more or less a nice to have. This is why we expect it to be ready much earlier. Not because the priority is for contracts. PolkaVM was specifically created because Wasm didn’t work well for contracts. We didn’t expect it to perform so well that it can also be used outside of contracts.

  3. I don’t think PolkaVM will be the blocker here. I assume the 1.0 Milestone needs to be done first.

  4. The most practical thing that comes to my mind is probably a storage migration :smiley:

  5. Our idea so far with debug ability is to use execution traces. Meaning that PolkaVM will collect a trace of an execution and sends that to the IDE. It allows you to go forward and backwards in time. This is different from an embedded gdbserver where this is not possible. It is probably also a much simpler protocol.

  6. Can’t comment on timelines.

3 Likes