When OPEN first announced the launch of our Scaffold Generator API in March of 2018, it marked the beginning of OPEN’s developer community. Privately we have been researching, testing, and experimenting to innovate upon the current limitations of blockchain technology and create the best products for mainstream adoption. Tomorrow, OPEN will officially announce its public Github and thus mark the next milestone for our developers – the beginning of OPEN’s public developer community.
At OPEN, we want to build the best infrastructure tools for developers and their end users and so we believe it is incredibly important to provide transparency to our developers and consistent updates on where we are going. In this document we will cover some of our architectural considerations as well as provide a brief roadmap for the future. We invite our awesome community to join us, provide feedback, and help us improve in developing the next generation Interoperable Data Sharding protocol.
OPEN envisions a world where all applications accept cryptocurrencies as easily as they do fiat currency. We know that applications of the future will not entirely be on the blockchain. Rather, the blockchain will serve as a kernel and do things that its technology is uniquely suited to do, such as payments, asset issuance, transparency, and auditability. In order to do so, the blockchain kernel must be able to interact with other parts of applications and their technology stacks. This includes enabling centralized databases to do what they do best. We are facilitating the early state of this industry, while simultaneously letting decentralized networks leverage their own benefits at the same time.
That is the core of what OPEN does — we let different representations of data, some in decentralized networks and others in centralized ones, communicate with each other in a scalable way. We also enable interoperability of this data across various decentralized components (blockchains) in a manner that mimics how technology companies and application developers evolved for the last 15 years – by making it incredibly convenient for developers to a) adopt b) develop on c) transact on.
OPEN focuses on two key pieces of technology:
Scaffold generators were publicly released for the Ethereum network in March of 2018. Since then, we have refactored the code to Kotlin and the Scaffold Generator, which lives at api.openfuture.io, will be live again on Monday, June 4th.
Additionally, we have built Scaffold templates that can be used by our integration partners and present a glimpse into what OPEN can do in the future. This coming week we will be revealing two of those templates, a Business-to-Business Invoicing Scaffold to provide a solution for software-as-a-service business models and other B2B companies. Additionally, we are also creating an In-Game Purchases Scaffold template that can be deployed by game developers that integrates with their applications.
These are first of many Scaffold releases to address common developer pain points that can be solved by using the blockchain. We will also be releasing integrations between the Scaffold Generators and our partnership blockchains.
Within the blockchain ecosystem, various types of blockchains have been implemented using different tech stacks and programming languages. Naturally, the stack consideration chosen for each of them is based on the requirements and goals that the specific project is trying to accomplish.
In our particular case, for OPEN Chain, our tech stack has been designed with the following qualities:
Moreover, for OPEN we will need a Virtual Machine where network participants are able to execute Smart Contracts including Scaffolds.
One possible solution to consider is Corda that utilizes the JVM tech stack. Corda would let us have a virtual machine with executable code and run Smart Contracts out-of-the-box.
Internally, we conducted a study among the existing Blockchain implementations and compared the pros and cons of each technical stack to meet our requirements.
|Well documented libraries||+/-||+||+||+/-||+||+|
We believe that Kotlin is a v2 of Java. It has solved lots of Java shortcomings: it does not have boilerplate code, language level is implemented at a Null-Safe, and the problem with Generics is fixed. Moreover, it is fully backwards compatible with Java, which allows you to call Java code from Kotlin and vice versa. This will allow us to use all the legacy and power of Java in the language of the new generation.
Implementing a UDP communication layer is more complex because UDP does not guarantee the delivery of messages. Therefore, it will have to be implemented independently at the application level.
Unlike TCP, the size of messages in UDP is strictly limited and in order to avoid fragmentation, possible loss of packets and to be sure that any host will be able to receive the packet, the data size in UDP should not exceed 508 bytes. This means that messages of longer length will have to be cut by 508 bytes, numbered and sent. If you take into account that the delivery of packages is not guaranteed, then from the recipient host to the sending host, you need to send information about packages that have reached the destination, while the lost packets need to be resent.
We can certainly implement the UDP communication layer, but it will take a considerably longer time and in the context of the DPoS consensus there is no strict need for this, unlike networks built on the consensus of PoW.
Given the arguments above, we are proposing to build OPEN Chain from scratch using Kotlin over the TCP communication layer.
One of the key parts of the Consensus is the selection of Operators and voting.
When a node wishes to become an Operator, it sends a request to the active Operators. Such nodes will be called Candidates. Operators check the Candidates for the requirements: availability, hardware and network characteristics, stack amount, the duration of stay in the network, etc. Similar to the rule for confirming new blocks, if a Candidate successfully passes the check of 2/3 Operators it falls into the list (queue) of Candidates.
Each node has up to 8 active connections, where:
By default, each node votes for the node that sends information about the new events faster and more often. Thus, Candidates have an opportunity to compete with Operators on speed and to be the chosen Delegates forming blocks and receiving bounties. Candidates in the queue are sorted by descending rating where the rating is the sum of all the derivatives of the voices and values of the stack. The rating is the sum of stacks of all voted nodes and the Candidate itself: candidateStackAmount + ∑(voterStackAmount).
According to DPoS Consensus, before each round, the Operators are arranged in a row, where each Operators is allocated a fixed time for the formation of the block. i.e. 10 seconds. During this time, the Operator must form a block and distribute it to other Operators to receive confirmation from 2/3 Delegates. In case of confirmation from the majority (2/3) of the Operators, the block is added to the blockchain.
If a node fails to form a block in the allotted time, it is excluded from the list of Operators. And the node following it should form 2 blocks in the next 10 seconds: one for itself, one for the previous node.
The round lasts until each of the nodes forms one block.That is, one round is 21 blocks (the number of Operators in the Consensus), if 10 seconds per block, the duration of the round is 3.5 minutes. At the end of the round, each node receives a reward proportional to the number of blocks generated and the transactions included in them. Before each round, all active Operators and Candidates are collected in the list, sorted by descending rating. Top-21 is selected as the Operators for the next round.
Our team will be publishing a more in-depth roadmap in the coming weeks, but we wanted to provide our developer community some initial insight. We will be publishing, at minimum, weekly posts updating you on our development progress.
OPEN Chain test nest net is scheduled to go live mid-september, 2018. We have begun our work on the TCP communication layer and expect to fully deploy by late July. This will be essential in leveraging our interoperable blockchain network and sharding transactions to achieve competitive levels of scalability. Concurrently, we will be building out our voting and consensus implementations and have the complete code open-source by mid August. We have already implemented the public key algorithms and will have Wallet Software updates beginning end of June and the OPEN Wallets available end of July.
More to details to be announced this week!
To reflect our commitment to creating the most robust developer community that is inclusive as well to developers who have only worked with centralized technology stacks, we have our Developer Growth pool which was created at the Token Generation Event and holds 20% of the OPEN Token total supply. This will be used to onboard new developers, create partnerships with leading companies, host hackathons and other developer events, and empower the community in many diverse ways.
We are proud that OPEN’s developer growth pool is by far the largest allotment out of any public blockchain project. With the first OPEN open source repository released on GitHub, our public technical community will begin. No matter where you are in the world, we encourage you to participate in shaping our mission as we provide you the best tools and resources.
The future is undoubtedly OPEN.