Technologies we use in blockchain app development

Here at Espeo, we specialize in blockchain app development. We’ve created both blockchain-based platforms as well as token offerings. Recently we even developed and launched our own open-source blockchain oracle called Gardener. As we make more and more blockchain applications our experience only grows. In this article, I’d like to share with you the technology stack we use in a few of the blockchain projects we’ve already accomplished. The projects I would like to focus on fall into three main categories: token offerings, trading platforms, and open-source blockchain tools.


Token offerings

In terms of token offerings, we’ve developed a few of them and we have a straightforward process and internal framework for this. Most often we use the Ethereum blockchain because of its leading position in the market. It offers stability in development and maintenance. Unlike other blockchain platforms, Ethereum allows us to make programmable smart contracts and it provides all the tools (Solidity) that makes development go much smoother. Also, Ethereum is open for public use, vigorously ensured in GitHub. It’s also proof-of-work based which makes it a perfect choice for enterprise applications.


We write Ethereum smart contracts in Solidity, which is an OO language influenced by C++, Python, and Javascript targeted to the Ethereum Virtual Machine EVM. It’s good to use the Truffle framework to develop dApps (decentralized applications). It provides an easy and comfortable way to code and test applications. For STOs, we run them using AWS Lambda and DynamoDB as data storage. Our AWS infrastructure handles all the operations from around the blockchain such as registering new users or storing address whitelists.


These addresses can perform operations on smart contracts. Our team uses AWS Lambda to run token offerings because it safely handles the traffic. Token offerings have variable traffic. In other words, traffic fluctuates between a flurry of growth at the beginning of the STO only to plateau and grow again after further promotion. AWS lambda lets us maintain the STO at minimal cost early on in a product lifecycle. If the interest in the token is big AWS Lambda can handle the traffic for us because it scales automatically.


Trading Platforms

In addition to the STOs we’ve developed, we’ve also helped design two trading platforms — CloseCross and Level01. CloseCross is about predicting derivatives value ranges. Multiple users can be a part of prediction events called virtual trading floors. Level 01 meanwhile, is also about trading derivatives but users can only play one-on-one. Prediction derivatives in Level01 are binary meaning users can only predict that something happens or not. We have called them trader and matcher. When a trader starts a request, a matcher matches this request with an opposite prediction. Both applications share a bit of functionality but both have some unique features that distinguish them from each other.


In both of them, we used Solidity and the Truffle framework to implement smart contracts. In Level01 on the server side, we employed Node.js. Its advantage is that Solidity is similar to JS so event if the developer only knows one language from these two, he or she can support the main developers in some small tasks.


By contrast in CloseCross, we wrote in Kotlin as the main server language and Node.Js to develop microservice which supports communication between the blockchain and our server. CloseCross is an event-based application built on RabbitMQ message bus. Again we run those applications using AWS this time using EC2 service. In both applications, we used Oraclize.It (now Provable) as an oracle for the blockchain layer.


In both blockchain app development projects, we decided which technologies to use in a collaborative process between the client and our development team in two-week iterative sprints. This working method leads to an optimal use of resources and the best possible product.


Gardener Oracle

The concept of blockchain oracles is that inside a blockchain there is no way to get information from the outside world. It’s the so-called oracle problem. So you have to have oracle which listens to a transaction on a blockchain and in response, puts some information into the blockchain. As I mentioned, we were using the SaaS tool Oraclize IT to achieve this initially. But after a while, we came with an idea to make our own oracle as an open-source product. Then Gardener was born – first open-source solution of its type. We have built it as always using Solidity and the Truffle framework to develop smart contract and Node.js on the server side.


Gardener is already a production-ready tool and it’s a complex solution which will fit in our future blockchain applications. You can host it on your own and connect to any open API with it. It comes with external libraries that help you integrate it with your smart contract. It supports different kinds of requests and different formats of responses. In the future, it will provide various modes which give you the possibility to decide who should pay for the request to the Ethereum oracle. It is a highly configurable system.   


Conclusion

Now you partly know what sorts of blockchain app development projects we’ve made at Espeo Blockchain. You also know what tools we use. We focus on stable and mature technologies to build our new solutions and deliver maximum value to the client. Some of them repeat because we value our experience with proven tools and knowing how to best configure them.


As is the case with Gardener, we also make our own tools to implement in our projects as well. Sometimes we experiment with new technology stack, then after the project ends, we look back on our choices and evaluate them. So far we have made enough systems which give us wisdom what tools fit our needs to meet client ideas and to deliver a product to the market as quickly as possible.