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:
Let’s start with something basic. The first game currency we want to build has just a max supply. We could write that without even using the expression engine.
Josh has been working on a brainscan v0.0 where we we show an expression, written into a simple contract, in this case ERC20 emissions which is powered by the Rain interpreter.
The expression is written in Rain script, a spreadsheet like expression writer. A simulation runs real time to tell you the rules for the wallet connected to the site and the expression is deployable using the Deploy Emissions ERC20 button when ready.
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?
As the Flow contracts progress through the QA process and test coverage improves, we can start to talk about things to do with Flow.
Yes there's all the marketplace, escrow, sale, mint type stuff you'd expect.
Maybe we can do something a little different and fun too?
One of the ongoing experiments we've been working on in our collective is a Rain-powered asset designer and marketplace. At the moment it's a "game designer" but in reality this could be applied to any kind of marketplace-as-gamified-economy.
Due to popular demand, I've recorded a demo of how you could use the Game Designer POC to quickly create a system of game assets, where the economy itself could be considered a game.
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.
This post is synthesised from conversations with the Game7 DAO during their grants process.
Game economies are struggling to break the 1-2 token paradigm and so the ‘play-to-earn’ movement is being revisited with people not sure what will drive the next waves of adoption from web2 to web3 gaming.
This week I experimented with our new 32 bit VM to create a viable implementation of 16 bit external calls. This is a really big deal imo, so I'll explain what's happening and why you should care.