I was thinking how we can simplify life for all the smart contract developers out there to run and test their software. When looking at Ethereum there is the well known truffle suite which can be use to develop dapps without running a node (you can simply use ganache)
When I did some deep dive into truffle, I recognized that there is a EVM implementation in JavaScript which is used to execute the contracts without running a complete node.
I was thinking if it makes sense to implement a JavaScript version of the FATE VM. This can serve as a foundation for developers which will then be able to build additional tools on top to support development on aeternity.
Additionally, Aepp developers targeting state channels could use the JavaScript implementation as the runtime engine for their off chain contracts.
This is definitely a must-have. Currently I don’t see any option that is more convenient to use than just being able to execute and test smart contracts in an in-browser bundled FATE implementation. It would have a huge impact on comfort and quality of using ground-essential tools like aestudio. At this moment either you install erlang and whole heavy node or trust a centralized server which is unacceptable as default for obvious reasons.
Beside that I am sure it’ll have positive impact on aeternity popularity – usability and intuitiveness are the first things that new people care of. It is crucial to make the introduction process as simple as possible. In-browser FATE would be a huge step towards it.
Short answer the it is needed but not enough.
Long answer would be something like this: there are 2 issues for executing contracts locally:
being able to run the VM locally
having the latest state tree locally
The execution is done by the FATE VM in the context of the state tree. If the contract asks for any on-chain data - the state tree is mandatory. It also must be the latest one, as otherwise the contract execution could be different.
This proposal is a great step forward as it solves (1). For 2 we would need some really smart PoI for the state tree. Basically we need an analysis what data of the on-chain world is needed by the smart contract call and based on this - fetch a minimal proof of inclusion, provide this PoI as a context of the contract execution and voila I don’t think I need get into further detail why we need a PoI instead of the state tree itself and this would start with how it is unfeasible to sync your phone with main net
Thanks for this useful overview on state channels. Regarding point 2: the smart pol you mentioned will be kind of a snapshot of the state tree only containing the relevant information for the contract execution. This will then be used to run the FATE VM in context of this state tree right?
I’m currently do some research and deep dive into FATE VM to get better insights and understanding of what will be needed to achieve an implementation in JavaScript
I don’t think I need get into further detail why we need a PoI instead of the state tree itself and this would start with how it is unfeasible to sync your phone with main net