The Seed project, similar to Ethereum, will allow for provable execution to occur on the blockchain in a decentralized manner. Ethereum pioneered this concept of a general purpose blockchain which allows for provable execution, and paved the way for multiple other implementations, such as NEO, ARK and NEM. Other projects took it a step further, such as Golem, which utilizes provable execution to allow for distributed computing to occur on scale, letting users rent the super-computer that is the GNT network. The potential for provable execution, for these general purpose blockchains, is limitless.
When designing a blockchain that has these extra features, a lot of extra work has to go into it. How complicated of an instruction set do you want? Bitcoin technically has its own instruction set, it is just very limited, however there are various types of messages a user can make. With Ethereum, that instruction set was deemed so complicated that they designed their own language, Solidity, and their own virtual machine, EVM, to give developers as much power as they could within the constraints of their language. NEO did not feel they needed their own languages, however the code is still compiled by NEOs own compilers into code to be run on their own virtual machine, which restricts the complexity of the languages you can use to be limited to vanilla features and NEOs API. These design choices, having simpler instructions, creating a language or not, creating compilers or not, creating a virtual machine, they all drastically change the complexity of the project.
Personally, I am of the opinion that complexity is not always needed (but sometimes is). Unneeded complexity often has consequences, for example complex projects are more likely to have critical bugs go unnoticed, such as the DAO hack on Ethereum that caused the initial Ethereum vs. Ethereum Classic fork. Other times, complexity is required as the benefits come from the complexity. Hashing and cryptography, for example, are both very very complex fields where the benefits derive from the sheer complexity. Let’s dissect the pros and cons of adding the extra complexity to provable execution projects, and determine whether Seed should have its own virtual machine or not.
The first questionable decision is the choice of creating one’s own language, rather than use an existing language. This has the obvious benefit of giving the blockchain developers full control over what can and cannot occur on their system. Creating the language guarantees they do not need to write a compiler or virtual machine which handles features you do not wish to implement. A simple example would be how, with NEO supporting C# (or more precisely, supporting the language C#/F#/VB.NET/VC++ compile down to before being interpreted), their compilers may need to support syntax features such as foreach loops, LINQ, Actions, and Funcs. The blockchain developer must support all vanilla C# functionality, whereas Ethereum’s Solidity is simpler, avoiding most syntactic sugars and extra features. Solidity remained very simple, with a system which disincentives people against using for loops and other costly computing. Creating your own language gives you full control over what you want and don’t want developers to do, and full control over which features are a priority to support.
However, creating your own language is a lot of work. It includes creating the compilers turning it into assembly or OPCODES. It includes creating a virtual machine to interpret this lower level language and run the code identically on all computer architectures. You then also need to support a development environment, such as online compilers for testing, API integration for contract compiling by other languages such as JavaScript or C++, documentation for an entire language and virtual machine, as well as testing to confirm everything works the way it is intended to.
In theory, the simplest way to do it would be to rely on a reconstructed language and compilers/virtual machines, and build the blockchain as a library. This has a bunch of flaws, such as as complete loss of control. You have no control over which environments someone is working in, what APIs they use additionally to yours, and no way to accurately measure execution times. However, it has many benefits. You do not need to make a language, and instead pick one other people already know, such as JavaScript or C#. You do not need to build a compiler, and instead trust the professionals who came before you and built Microsoft's C# VM or JavaScripts Electron. You do not need to run documentation for the language or virtual machine, just your API. And despite not having full control over their test environment, tests can still be run locally to confirm that the environment your code is executing on is behaving appropriately, however this does become harder.
It cannot be completely free to execute code on the blockchain without having to deal with additional flaws. For example, if it was free to execute anything, someone could put an infinite loop in the code and break the virtual machine. Ethereum deals with this by counting the GAS each opcode that gets run in the virtual machine, only executing the code for as long as the senders GAS does not run out. Once they run out of GAS, the execution halts and transaction fails. This prevents developers from putting any costly logic in or malicious code which may drain the funds of the sender, wasting funds without accomplishing anything. Ethereum and NEO each charge GAS per opcode, however with Ethereum, that GAS is charged at a Eth-per-gas free-market rate, whereas in NEO, the cryptocurrency GAS is the GAS being charged. This difference is the same as far as how the code executes, however differs in regards to their economic models.
EOS is another project on the horizon. In EOS, GAS will not be charged, it will be up to the nodes running the delegated POS system to determine what is acceptable speed and what is unacceptable for contracts to run. So rather than charge a fee per execution, the nodes can simply decide "This contract has a function which takes too long to run, I do not approve", subjectively determining, keeping the specifics as implementation details. This is an interesting way to go, as the vagueness future-proofs the project. Memory might get to the point where it is effectively free or get to the point where we can do loops over millions of objects in an array, however Ethereum will always charge the same opcode costs per execution until a fork occurs. The fuzzy execution cost of EOS does raise some flags, as some critics claim lazy design. However, as I said at the start, Im personally a fan of reducing complexity when it is not needed, and am excited to see if EOS can function with their subjective costs.
After debating it, Seed will most likely not use a virtual machine or language. As it stands, the plan is to use vanilla JavaScript in order to build an API for Seed that is supported by all web browsers, as well as Electron. This decision is due to two major factors. The first and foremost is because the goal of Seed is to be able to power a browser based web MMO video game. JavaScript is the language of the web world, minus a few competitors that are less used and supported for clients. In order to maintain control over what code is being executed, Seed will take advantage of provable execution with function hashing, which not only validates which functions users call, but also validates that code was not injected into the functions before execution, and should a user manipulate the data in any way, breaks the resulting hash as well. JavaScript is not a secure language, however blockchain and cryptography is secure by design. I'm confident we can achieve the desired security.
The second reason behind the decision is due to time. Seed is a year long research project being created by myself and my partner 
Finally, as I stated above, I dislike redundant complexity. I do not feel that we need to create a language, compilers or virtual machine. Not all browsers will execute the code the exact same, however most of the core vanilla library is the same on each major browser, and following the consensus system of Seed, someone whos browser gives conflicting code executions will simply be told their world is not the true one. They would be able to listen to the world, however their participation would be halted until they switch to a browser which agrees with the execution of the majority of users. I feel that is fine, and the extra control is unnecessary as long as we pair vanilla JavaScript with the provable execution with function hashing.
Seed code will not have an execution cost. How we will avoid infinite loops is currently uncertain, and is a problem we will need to address. However, rather than a Ethereum inspired GAS cost, Seeds execution cost comes from the cooperative approach to proof-of-work/stake. This method is similar to IOTA, where users validate previous transactions before being able to broadcast theirs. Users must execute code of other clients and validate the result whenever they do their own execution. Therefore, your cost is not paid in a GAS fee, your cost is paid through the work you put. There are no miners in Seed, only users and relay nodes, so users themselves need to validate each other, rather than pay a fee to miners/consensus nodes who do the work.
Thank you for your time and reading! This has been an internal debate, we've gone back and forth on the matter, however we believe we are firmly sticking to making JavaScript work. With provable execution and function hashing, I believe it will be adequately secure. This saves us a lot of time not needing to make our own language, virtual machine, or development environment for users, and severely reduces our documentation load. Thanks for reading, upvotes or follows are always appreciated!
