With @koute’s help here, we were able to compile our first JAM service built in Rust into PVM byte code. Woohoo!
Amazingly, its nothing more than a “cargo build” and a polkatool call. No more hand assembling PVM byte code like its 1964! 
We opened a draft pull request here. Check the README for details.
We should be able to prepend a header soon to make this byte code fully GP-compatible/JAM-ready within polkatool, enabling JAM implementers to fold Rust-built JAM Services into JAM’s guaranteeing/assuring/auditing/disputes processes.
The first few JAM service builders can aggregate JAM Services examples here showing many of host functions in action in the context of refine-accumulate for multiple languages: Rust right now, C/C++ surely, Solidity (with revive), and maybe other languages too.
11 Likes
Why did you choose to close that draft pull request?
Just remember, accumulate should never have much CPU time, probably not even enough for a signature verifications. Accumulate should only copy around hashes between the block header(s) and RC state. Anything more than copying hashes is likely to be a poor design, maybe extremely expensive, and probably results in low throughput or stalls.
The big deal we market is you can have more than one mutable state root, which is the “actor” model. This matters for smart contract chains like moonbeam because they can shard state to use more core than what’s possible with elastic scaling.
If you have a true dApp chain, maybe you want the actor model, but probably you can do better with only one multable state root per chain, plus multiple immutable ones, aka off-chain messaging. Anything with exactly one mutable state root like this should still be considered morally the “parachain model” plus off-chain messaging, although it’d likely worth using the service frameworks to avoid problematic design choices in frame.
Internally, another big dal is you can have zero mutable state roots, which allows more “unstopable” system services for elections or DKGs. I donno if zero mutable state roots is ever useful for customer services.
1 Like
These services were just toy experiments for us to understand the refine-accumulate services architecture, and now we know what the point is: CoreVM and CorePlay programs – similar to how applications outnumber OS by 6-8 orders of magnitude, there will be a low need for JAM Services: CoreVM + CorePlay will be enough, and there should only be a few other animals like these. We don’t really want multiple CoreVM OSes, since there is just one thing CoreVM compiles to: PVM.
We’ll have a CoreVM service published soon .. and then we will want not lots of new JAM Services but lots of CoreVM programs, and CorePlay programs. We should ready product management around CoreVM/CorePlay and not JAM Services, supported by teams getting linear recompilation in order this summer + fall.
1 Like