Latest Tweet

Thoughts on making EOS development easier

I started writing my first smart contract for EOS and I had to overcome some hurdles.
This is to be expected because EOS is not even released yet, and we’re working with a rapidly changing test version until June this year.
Also, the only information comes from the GitHub’s wiki, the rest is only documented in the code.
Still, having everything set up and running, I have to say the developer experience of developing smart contracts leaves a lot to be desired.

Here’s what I need to do every time I start working on my EOS project:

Start a virtual machine running Ubuntu 16 with my EOS installation.

Run a local test network: Start the eosd service that listens to and processes my transactions and produces blocks for the blockchain.

Open a wallet containing the private keys of my contract test accounts with eosc wallet open -n default

Unlock that wallet with eosc wallet unlock -n default <<< 'password'

Here’s the cycle I go through while developing:

Make changes to my smart contract’s .cpp file.

Compile it to WebAssembly with eoscpp -o contract/TestContract.wast contract/TestContract.cpp

Whenever the ABI (the smart contract’s public interface) changes, I need to recompile it with eoscpp -o contract/TestContract.abi contract/TestContract.hpp

Upload the changed smart contract to the blockchain with eosc set contract test contract/TestContract.wast contract/TestContract.abi

Of course, blockchain dapp development is still in its very early stages and a lot of tooling is missing which will come later in time.
But why wait, when we can change the future right now.
Here are some thoughts on how smart contract development could become easier.
It’s a good idea to completely forget how things are right now to get a perspective change and start by asking:

What would it look like if it were easy? - Tim Ferris

What would dapp development look like if it were easy?

It would look something like this:

No initial setup phase. You just create a project. (Maybe some initial project specific configuration.)

You change the code of your .cpp smart contract and press save. It is compiled and the smart contract is updated on your local testnet.

You run a bunch of tests against your newly deployed smart contract.

How can we achieve this?

Ethereum already has a great development environment Truffle that does a lot of these things:

Truffle also comes with Ganache which is an internal Javascript implementation of the Ethereum Blockchain available on all platforms.

The ultimate goal for EOS should be to have something similar to Truffle.
To quickly prototype and play with the EOS test versions today, we could also do the following:

Move the EOS test blockchain to the cloud. For instance, we can run a Digital Ocean droplet with Ubuntu and install EOS there. You can communicate with the remote eosd by specifying a host and a port in the eosc command:

eosc -H -p 8888

Use eosjs for the API calls and for writing tests. EOSjs is a JavaScript general purpose library for the EOS blockchain.
This way, you could get rid off your local EOS setup.

This way we solved how to tests your EOS smart contract in a nice way.
We could add a watcher that watches for a file change of the .cpp/.hpp files and then runs a script that recompiles them and deploys to our remote test blockchain.
Adding the contract account’s private key to the keyProvider array should be enough to sign the transaction, meaning we can also get rid off running our unlocked wallet locally.
This gets us quite close to the goal of not having to set up EOS at all locally and just running NPM scripts to communicate with the EOS blockchain.

These are just some ideas that crossed my mind while developing my first EOS smart contract. I’ll try them out and improve them. After having a workflow that works well for me, I’ll then create a follow-up post.

It would be nice to hear how your EOS development workflow looks like.