Today we merged the standalone version of the interpreter which ships as a mere
interface from the perspective of the calling contract. New words added and
significant changes to Flow usage and security model.
I've been working on converting all the interpreter work into an interface that can support standalone interpreter contracts. This will bring several benefits:
I don't think it is immediately clear at all what it means or why it is good to have a "rain interpreter".
The EVM already has general purpose set of opcodes for smart contracts, why do we want to reinvent that wheel?
How is a Rain interpreter different to the myriad of languages like solidity, vyper, etc. that are high level, battle tested and compile to the EVM?
How can this possibly be gas efficient, useful, secure, etc.?
Everything that Rain can possibly do could be coded in Solidity (the Rain interpreter itself is Solidity) so what's the point?
This week I spent some time on a general purpose struct that defines token movements. In the near future this struct and associated logic will replace the EmissionsERC20 contract.
This is all a leadup to "adminless upgrades" for interpreters (previously known as VMs) that I'll try to get working "soon".
In short, this is the crux of the flow code in Solidity from this week.