This week has been incredibly wild for us, as we’re sure it has been for our community too.
Since the Asia roadshow, over 10,000 people have now joined our Telegram, pushing it up to 62,000 people. On the roadshow we announced several technical partnerships and outlined how OPEN will be building the future. We have still been hard at work engineering and in this post we want to give our community an update.
As you may have read in our previous post: OPEN has decided to utilize Kotlin for its blockchain development for numerous architectural reasons over Java, the next best option. Comparatively, Kotlin provides OPEN with better memory management, cross-platform capabilities, multi-threading support, is open-source, has well documented libraries and is supported by the community, as well as by Google.
Further research and development on our side has only supported that decision so we have begun the process of refactoring our existing product to suit this more robust architecture. We have made significant headway on developing a Scaffold 2.0. We will share in more detail below. Our team has also made specific decisions on how we want to structure OPEN Chain which will be briefly discussed after.
We have begun the process of migrating our existing Scaffold and API code to Kotlin. Here is a summary of our primary activities:
|Google Oauth||Authentication to the application using google account.||Done|
|Logout||Logout from the application with redirecting to the main page.||Done|
|Get current user||Getting information about which user is using application now.||Done|
|Save user after authentication||If the user is authorized for the first time, we will remember it by saving to the database.||Done|
|Scaffold template processing||Scaffold can changed in runtime because of scaffold properties. So, we implemented functionality to process scaffold template with this properties, and creating new scaffold on each user request.||Done|
|Scaffold compiling||After creating a scaffold, it is necessary to compile it to check correctness and get additional information like abi, interface, bin, etc.||Done|
|Scaffold deploy||After compiling we deploy scaffold into blockchain.||Done|
|Scaffold save||After deploy we should save information about scaffold into the database.||In Progress|
|Get scaffolds of current user||Functionality for displaying the user’s own contracts||Done|
|Get scaffold by his address||Functionality for getting scaffold by his address||Done|
We will be releasing much more technical posts in the future, but we hope to outline how we are structurally building OPEN Chain.
Our HTTP Layer will be implemented using Tomcat serves with a RESTful API because it provides a clear and reliable situation. It also enables us to iterate more rapidly as it is quicker to develop and improve upon.
OPEN Chain’s Node Communication Layer will be implemented using the Netty server with a custom communication protocol. This will include a unified API for non-blocking socket. We based it on a flexible and extensible event model which allows clear separation of concerns.
It features a highly customizable thread model. With this we are able to achieve better throughput and lower latency. Finally, there is less resource consumption and minimized unnecessary memory copy.
Our overlying communication protocol will build using Google Protobuf. Protobuf provides a flexible, efficient, and automated mechanism for serializing structured data. It allows us to update data structure without breaking deployed programs. We are able to the quickly write and read structured data to and from a variety of data streams.
We hope this provided some clarity as to what we are currently building at OPEN!
We will be releasing more technical updates in the near future on a more granular level than what is seen on our timeline. We are excited to show you exactly how we’re progressing on changing the world!