White paper

Executive Summary

What is Cellframe?

Cellframe is a service oriented blockchain network. It is built very close to the hardware, to provide efficiency of use on any machine — from supercomputer to smart fridge. Post quantum encryption is a default one to provide the highest level of security. Important to note that we did not try to invent a new unproven yet essence or technology; we are making the blockchain the way it should be done to be called an infrastructure.

How can it be used?

By design, Cellframe’s architecture is a structure with a dual-layer sharding. The first layer (heterogeneous layer) can launch customizable subchains and tokens. On the second layer (homogeneous layer), subchains are organized in Cells. Due to interoperability features we plan to build an ecosystem of services where every app (or dapp) will have an opportunity to exchange information with another app in a p2p manner.

Our mission is to create a safe decentralized environment sustaining the freedom of the Internet making people more confident and calm in the everyday usage of it.

Cellframe is public and enterprise solution at the same time

Performance and scalability of Cellframe meets not only demand from the public blockchain market, but also from enterprise can widely be used for enterprise solutions. Here we have a couple examples of use.

1. Service-oriented architecture make easier to build 2nd level protocols with dedicated services. Built in payment system and private shards(networks) gives ability to focus on service development itself, when conditioned transactions make 90% of typical smart contract operations without them (less gas consumption, higher security, simpler development, lower development risks and time.
2. We already have an enterprise blockchain-in-a-box solution ready. Besides, one of the most interesting solutions for all of the public and private blockchains is a securitization (insurance) from terminal attacks.
3. Due to its architecture, Cellframe is the only system that can protect a blockchain from terminal attack (incl. quantum) without users migration and implementation of a third party code.

Abstract

Cellframe documents our vision of a blockchain platform with fundamentally broad functionality, capable of building and delivering a variety of high-demand, high-load, high-security services. Cellframe is the zero-level protocol for building the services underpinning emergent Web 3.0 business models, adding not only the performance and integration required, but also an integral foundation of post-quantum level security. The key innovations are decentralized services, new fine sharding implementation (which offers performance and resilience) combined with a low-level architecture (performance and security) and a high level of modifiability by design (flexibility).

Challenges

History teaches that no man can predict the future. We are offered predictions by smart people in the press and books, and know invariably that some will come true, and others will not. While it may be difficult to find a single reliable truthsayer, we can note that certain macro phenomena about guessing the future seem reliable: people tend to overestimate the rate of change in the nearby future and underestimate it in the distant future. Taking this into account, let us carefully separate the facts from opinions and build a suitable, in our opinion, narrative for the further development of our technology.

1. Fact #1: The dynamics of generating new information is growing. What does this mean for creating the foundational technology for the future industry? Maybe it's time to track the dynamics of growth? In addition to the need to deliver on performance and efficiency, a basic infrastructure protocol also requires extensibility and flexibility. Other than an insatiable appetite for performance, we invariably can not predict future needs and inventions and must safely support improvements and modifications that will undoubtedly appear.
2. Fact #2: The technological limit of the size of the transistor of modern CPUs is very close. According to various estimates, in the period from 2021 to 2025, we will not be able to reduce the size of the silicon chip as it will be limited by the size of the atom. Therefore, an infrastructure protocol that wants to be future-proof will be efficient and scalable across a network. It is about maximizing usage of available computing resources and interconnecting these resources in effective networks. Understandably, we maximize performance by building code as close to hardware as feasible using plain C and low-level hardware optimization.
3. Fact #3: Quantum computing has been getting increasing worldwide attention. Certainly the largest cryptographers are riveted on quantum computing progress. The Post-Quantum Cryptography sector is now engaged at NIST (National Institute of Standards and Technology), sifting through dozens of algorithms and protocols, in search of an industry standard. We expect this standard will take more than the coming year to resolve. While a functional quantum computer is still somewhat indefinite in its delivery date, we are now making plans. PQC is also developing its own specifics. Any future-proof architecture must work equally well with both classical cryptography and post-quantum cryptography.

Vision (design goals)

Cellframe was born as a response to the challenges we have described, leveraging design goals we believe will squarely address our coming future. It offers:

1. Low-level architecture. In order to maximize the efficiency of the protocol, it must be built in such a language so that it can speak without kernels with the kernels of any operating systems and be efficient in working with both mainframes and smart refrigerators. This is why Cellframe is built entirely on C with no third party code.
2. Zero level protocol. Over the past years, we have seen the emergence of dozens of different protocols, each of which wanted to improve or change something. This activity signals that people want to apply technology in various fields. However, till now they do not have the universal platform that would offer effective tools for solving their problems. From our point of view, it looks like an attempt to invent “a steam engine” before the invention of the wheel. This is how the Cellframe Tissue concept was born, which will be discussed later.
3. The inability to predict all the tasks that will be solved using Cellframe. In other words, the protocol needs the ability to be modified without compromising security and performance to solve a particular problem, which means it should already be flexible (or variable) by design.
4. Decentralized services will eventually replace the infrastructure on the web removing multiple points of failures.

The infrastructure is a complex of interconnected service structures or objects that provide the basis for the functioning of the system. Our protocol was originally conceived as an infrastructure (wiki), which means it was created for high loads and a high level of interactivity. We are creating a flexible and efficient system, each element of which could be used to solve different problems with different characteristics. If the load on a specific Cell increases to such a limit that it interferes with efficient functioning, the owner of the Cell can create any number of Cells in support of the first one. Different Cells in the same system can perform different functions using smart contracts. As a result, the system of different Cell forms Cellframe Tissue, the second most important "organ" of the system. The first is zeroChain. The architecture of the resulting system allows us to reach a gigantic level of scalability and virtually infinite bandwidth and create the maximum level of security.

The motivation behind the proposed system is an intention to create a system which can be both used for independent, decentralized applications as well as enterprise solutions. Truly decentralized services and applications can exchange microtransactions without overloading the system. Due to a built-in payment system it works cheaper without smart contracts, in other words, cheaper and more secure. Besides unprecedented vertical and horizontal performance, variability and developer friendly approach, this will be achieved by implementing instruments to reduce the cost of mistake — arbitrary acts. From the start the system will be launched with a combination of Proof-of-Genesis (<1% or total blockchain consensuses) and Proof-of-Stake (up to 99%) consensus mechanisms.

The network itself consists of dependent peer cells. The network can launch a chain with their own attributes, own token, type of consensus without unbreakable bond with zeroChain, etc. This is why these Cells are called syngeneic — they are similar to stem cells (which easily can convert to any specific cell type in the human body). This metaphoric comparison means that each shard can be launched with any possible attributes and connected to any shard. Administrative information about Cells, tokens and its initial ledger’s locations are stored in zeroChain, which has a PoG mechanism. This decision also has two consequences:

1. pseudo centralization of the system is leveled down by the opportunity of creating pseudo-dependent Cells, which can’t be affected by arbitrary acts or deleted by root nodes because all of the inter-cell communications are direct, i.e., peer-to-peer;
2. In the future, we plan to implement the type of consensus that can actually be able to govern the decentralized system.

Using this mechanism, Cells become homogeneous and have a high level of inter-cell communications. Сellframe hierarchy also presumes a fractal-like model: each Cell has an initial Base Chain inside. This Base Chain is similar to the zero Chain of the whole protocol but for specific Cell.

Summarizing all the above, Cellframe is not a blockchain protocol, we can call it an infrastructure layer for building a blockchain ecosystem. All existing blockchain solutions can be transferred to Cellframe and get previously unattainable performance and security levels.

There is another question that we would like to discuss in this chapter. A lot of bright minds have been working in the blockchain sphere in recent years. Then why do we think that there is a room for Cellframe on the market? Does this mean that no one in the whole sector is moving in a similar direction? What caused the current situation?

The development of any technology passes through stages or generations. When some generations show their inaptitude, we learn and create new, better ones. The blockchain technology today has several fundamental problems that we described above. The ways to solve them can be divided into two groups:

• Tactical problem solving is reflected in the improvement of specific components of conventional systems. This way most projects from the blockchain sector are moving, since it is less labor-intensive. They work with a system that has already proven its effectiveness at a certain level, which they consider sufficient.
• Strategic problem solving is like an attempt to create a new technological platform (system), which is fundamentally different from existing solutions. Fewer projects are moving in this direction, since it takes time, is labor intensive, and requires a deep understanding of computer networking devices and cryptography. E.g. The first private version of dev net of Cellframe was launched about a year after the start of the project in July 2018.

Highlights

Variability

Usually, blockchain developers try to save every byte of information because a blockchain size often is not a key priority due to the fact that the price of disk space keeps decreasing. Because of flexible structure, we’re not limited with this fact, so it is possible to add little more bytefields in the wallet’s address, event headers, signature and public key structure, network protocols and other shared structures that need to be recognized by software for processing.

Little more bytefields give us the ability to create more transactions types, signatures, events, wallets, datums and other data structures on the fly without total code reconstruction, blockchain structure change, new wallet types issuing, etc. Variability to produce backward compatibility between different versions and prevents version incompatibility.

Security

Security in the Cellframe is achieved mainly due to the variability features – it does not rely on any particular signature algorithm and due to the multi-client use – on a single consensus. Safety standards become more complex over time. If you use one specific algorithm, then the stability of this algorithm will determine the stability of the entire system in the context of encryption hacking. Since we are working with the concept of a quantum computer and quantum encryption, it was necessary to create a system that will not be dependent on this factor. In other words, you need an ability to safely change the type of encryption to increase security. The same applies to the type of consensus mechanism - our task is to create a system where you can quickly change the algorithm of consensus either in the current cell or with the creation of a new one.

In case of any problems, we will be able to quickly locate them and prevent their distribution throughout the system isolating a shard or using arbitrary acts as a security mechanism in the first several months after launching mainnet. Arbitrary act is a mechanism that can mark a transaction as invalid and roll it back. This feature is planned as a temporary measure for the first year until the system is stable enough. Also, there is so-called Rat Announcement that could be issued by any Node, then verified with the Root Node and placed in a special Support Chain where Arbitrary Acts, Rat Announcement and System Warnings prevent both of possible attacks or reduce the damage from them. This is how zeroChain announce that it has found a malicious participant.

The entire Cellframe system in its architecture almost does not have third-party code, which also increases the overall security level. This means that all the code has already been written by our engineers without the use of third-party modules — there are no known vulnerabilities and hacking methods.

Supersingular curves and lattice permutations are used as the basis. Implementations of such algorithms for public key communications are already available on the network, as well as some variant signatures based on supersingular curves.

Scalability and Performance

Node structure scalability of the Cellframe is robust and limited only by the hardware power. Since we use low-level optimization and organization from scratch, we do the high throughput system with extra good parallelization. The curve of productivity growth related to the hardware power is almost linear. Node capability is planned to handle up to ten signatures without any lags and even up to 100–gigabit traffic if it is equipped with the appropriate number of CPU, RAM and well-established traffic distribution between them.

The event-driven architecture is making all these possible. There is an I/O grouping in such a way that all the same operations are performed in a row in non-blocking mode. This allows us to optimize them at the level of OS's and hardware, and furthermore to optimize I/O additionally due to its grouping in one place. In turn, it allows using Zero Copy technologies (or similar), by sharply reducing the load on so-called “context switching” and it is impossible to work at high speeds without it.

The network scalability largely corresponds to the scalability of any peer-to-peer system but with a single nuance. Given the fact that the uplink node is searched by the principle of the shortest network path, our network should function faster and have a quicker response time to external requests. Data is transferred with the shortest possible latency. Latency in the multichain system leads to an increase in the number of chains and extension of rounds, plus its influence on the time needed to spread changes in the network. We cut the latencies and increase the speed.

Supersingular curves and lattice permutations are used as the basis. Implementations of such algorithms for public key communications are already available on the network, as well as some variant signatures based on supersingular curves. We plan to "invert" and modify it into algorithms for a digital signature forming, some of them are already present on Github.

dApps: how to make them truly decentralized?

Information today transfers almost instantly. The number of possible social connections is limited only by access to the Internet and a computer. One of the crucial issues nowadays is trust. How can we trust and verify those we communicate or work with? During the last century, humanity was focused on the complexity of verifications. Governments started using passports and identity databases which collect almost every move of citizens, in addition to visa systems with several levels of control. Compliance departments now are very significant divisions in almost all major banks.

At the end of 2008, the Bitcoin network whitepaper was released. It proposed a pseudo-anonymous peer-to-peer trustless network. It doesn’t require trust in ordinary meaning, as the network architecture itself provides an unconditional level of trust between its members. After this, the industry of blockchain has come a long way. We saw the hype caused by the first appearance of smart contracts, which was followed by the ICO bubble, the first serious governmental implementations of technology along with ridiculous things like tokens for memes or garbage mining. Today, almost all the companies from the Fortune 500 list established blockchain departments. Many world celebrities managed to either make a lot of money or receive a fine from regulators for the promotion of crypto scams.

The market of dApps has been developing rapidly in recent years. In just one last year the dApps industry demonstrated greater traction than the entire blockchain industry in 2017-2018. For example, the Defi sector, represented mainly by Compound, MakerDAO, Synthetix, and Uniswap according to defipulse.com recently reached $1bln worth of frozen assets in their contracts.

Yet, very few people outside the developers' community understand how smart contracts really work and what their technical limitations are. The popular opinion is that “smart contract” = “secure, trustless system”. But this is not exactly true. And we are not only talking here about Ethereum scalability issues. Speaking of limitations, we mean functions that cannot be performed by existing contracts. We'll discuss it further, as well as some security issues of which many ordinary users are unaware.

Problems of current dApps architecture

Despite the decentralization of the Ethereum network, we can (rather conditionally) say that the smart contract is de facto “owned” by the private owner(s). This person(s) can become a tidbit for hackers if there are significant holdings of digital assets in the contract. Thus, there are one or more critical points in the system. So, properly executed attack can lead to loss of users’ funds.

If the funds would be distributed to an unlimited number of private key holders (as is the case of the Cellframe blockchain services), even if someone would steal your private keys, the money will be stolen only from this person. Other participants and users of the service will not be affected.

The second drawback of the existing contract architecture are the limitations applied to business logic, that can be implemented into a contract. Taking into account limitations of the EVM(in the current configuration) it is not possible to interact with the hardware resources of the computer, which cuts off the possibility of implementing a wide range of dApps.

Described drawbacks limit the ability to create dApps to the level of a smart decentralized “calculator.” Of course, a simple business logic such as “simultaneous transfer of assets upon condition” or “if the token is frozen in the ERC20 contract, then...” is relevant and sufficient to create a lot of useful decentralized services, what is proved by the success of Defi sector. But, today the market for such dApps is still small if we are talking about real numbers, outside of a few crypto enthusiasts. At the same time, there are a vast number of services where decentralization would affect the lives of billions in a positive way. We can assume that anyone reading this article uses these services every day: DNS, cloud storage, VPN, CDN, and many others. Of course, there are a number of projects that are creating decentralized analogs of file storage (Filecoin, DADI) or VPN (Sentinel, Orchid, Lethean). However, none of those initiatives so far has turned into a project on a mass scale in terms of user base or any other metric. In essence, projects either have not reached the mainnet stage, or their audience is limited to a couple of dozen crypto enthusiasts. We suppose that there are several reasons for this, including the imperfection of the current blockchain architecture. It is not anyone’s fault – these blockchain platforms were not developed for this purpose. As a result, it is necessary to build a lot of things additionally. In this regard, each project is trying to solve the particular problem of building a blockchain service (and very often from scratch), which is completely ineffective. Using approach looks like reinventing your own web server to run a website, rather than taking well-known Nginx. We think that the solution to this problem can become a special blockchain framework that can be customized for a specific task of creating a particular blockchain service. First of all, it will reduce the time of development and narrow the scope of work – as CMS did a decade ago for building a website.

Cellframe: service-oriented blockchain platform

We decided to close this gap with Cellframe SDK, to allow anyone to create decentralized Internet services fast and easily.

As mentioned earlier, in current solutions (like Ethereum, Tezos, NEO, etc.) smart contracts can't interact with operating system resources. In contrast to other platforms, in developing Cellframe we aimed to create a framework, which would allow building business logic around the usage of computer resources, such as computing power, Internet channel, and disk space. Also, we kept in mind the decentralization of the ownership and protection of end-users. As we mentioned before, the classic smart contract has an address from which it was deployed to the network, while the Cellframe-based blockchain service is inside the system and does not have an owner address. Yes, the Compound contract, which stores $5B of crypto, has a specific owner. What if it wouldn’t? We think that it can reduce the risk of fraudulent activities or illegal use of a private key (note, that even if you have an institutional-grade private key management system, it ultimately has a chance to be stolen). We think that cash flows generated by the service have to be in a reliable way distributed among the service providers without having to pass through the owner of the smart contract. We propose to define such kinds of decentralized applications with the term “t-Dapps” (true decentralized applications).

At the same time, the process of developing blockchain services have to be no different from creating web scripts or other system services. Such an approach will make development easier and cheaper as you don’t need to hire specialized blockchain programmers, who are much more expensive than developers from the “traditional” areas.

Yet, these two principal approaches to build dApps have their own areas of efficient practical application. There are situations when a blockchain service cannot replace a smart contract due to fundamental reasons. For example, the main case is follows: you need to create a dApp, business logic of which doesn’t rely on installation of a service node and maintaining them online.Also, we can highlight an opposite situation where blockchain service will be preferable than a smart contract. Here we are talking about applications where necessity of running a certain number of physical nodes and maintaining them is a crucial point of a service model, and you can attract enough users who want to provide the service (by launching the node) as well.

Cellframe is a platform for creating blockchain services, in which the problem of scalability is initially solved. To achieve high scalability, we use sharding, but not in an ordinary way. In Cellframe, we eliminated the bandwidth bottleneck – the intermediate hub, which is commonly used in some blockchain platforms (for example, Polkadot) for the exchange of information between chains. Cellframe shards can interact autonomously in p2p mode, which ultimately increases the performance of the entire system. Talking about security of the system, we took care of how Cellframe will work “tomorrow”, in the era of quantum computers. It is the reason why we protected the system with variable quantum-resistant encryption.

Our vision is that decentralized Internet services (blockchain services) would become one of most important components of web3.0 architecture, similarly to centralized services in the era of web2.0. Of course, we have no doubt that decentralization of value transfer (bitcoin, stablecoins), as well as simple fintech applications (Defi), is a significant contribution to building the Internet of the future. However, as long as the base Internet layer can be completely censored as it is centralized, all this will have a lack of integrity. How valuable is the opportunity to send bitcoins or tokens if your connection can be censored? We strongly believe that to build effective web3.0 it is necessary to solve the task of creation of infrastructure modules that are safe and would not have a single point of failure.

As closing notes, we want to point out that substance, flexibility, and freedom are the values that Cellframe is based on. We (and millions of people with us) are convinced that the Internet needs change. No doubt, that centralization creates a dangerous fragility. What does the Internet worth when a single decision made by politicians or a corporation can threaten access to information and communication opportunities for millions of people?

Cellframe Core

The Core code is based on entirely original C-code with its object-oriented programming. Everything else utilized is original: the HTTP protocol realization, key exchange, streaming multiplexing, low-level services like VPN, CDN or edge computing. We stick to this approach to exclude ready-made hacking tools and speed up network event handling.

Because of the low-level optimization and event-driven internal structure we aim it to be able to handle the unreachable level of performance. We reduce the number of queries to system functions and their associated so-called context switches. This is how we avoid data processing ceilings which can appear by using large amounts of data at high speeds, and these switches can grow exponentially.

Blockchain Structure

The main idea of Cellframe is multiple subchains, containing Plasma (any blockchain element) inside of syngeneic Cells (shards). ZeroChain is single line plasmas that work over all the cells and hold inter-cell communications.

Node

Node is the atomic element of the decentralized network. Most of the nodes have the same privileges in the system, so it is a “one-rank network.” We should mention that we need several particular types of nodes: light, full, archive, master, root or any private nodes possible (seed, gate, swap, etc.).

Nodes can share Services via Network. Services can use their own identifiers and share blockchain data, whitelisted data, stream channels, and other Cellframe Network feature abilities. Since everything is developed in a relatively low level language, we can share instruments for creating services such as VPN and Audio-Video streaming due to effective CPU and memory usage. Post Quantum algorithms are very heavy and to optimize its use with high throughput (1+ M TPS) we have to use Assembler optimization.

Nodes Organization

The node organization is performed with the help of a whitelist – a list of nodes with an uplink for each of them, which is copied from node to node. An uplink itself is a node that requests the entire whitelist at the first connection, and the non-blockchain data obtained from it is considered to be the preferred one. That means, if the downstream node sends a whitelist conflicting with the parent node, the preference will be given to it. Although at the same time, a list comparison with all other nodes of the network will be required. If an IPV6 white address is available, there is always the possibility of a p2p connection to any other node. The uplink during the new node connection is readily determined – the whitelist is downloaded from the so-called “seed nodes” (center nodes), where data is requested by default and then traced to each location, and it turns out to be clear which Internet route is the shortest with the minimum response time. Thus, the nodes will be built into a hierarchical scheme that will roughly repeat the hierarchy of the real Internet.

Merging into the network

Nodes are merged into the network by the following algorithm:

1. Try to connect with root nodes
2. When connected, asks them for node whitelists and their IP addresses
3. Track nearest nodes according to their white IP addresses, selecting the closest
4. Ping them and try to handshake with them to measure the lesser latency and higher speed
5. Connect to the 2-5 of the best node
6. The 1st node gives you your new id based on a key generated for it.
7. Synchronize blockchain with uplink nodes
8. Request address, broadcast you node’s public key and services price-lists into the zero-level blockchain
9. After the key is accepted in blockchain — the node can share service

Node Data Processing

From the "Internet" the connections come to node from clients – C–0, C–1, C–2 and so on. After that, the connections are assigned to a certain worker, w–0, w–1, w–2, and so on.

The number of workers is strictly constant and is usually equal to the physical number of processors in the system. Accordingly, a worker is a separate thread strictly owned by the processor, i.e., executed solely on it. This allows the system driver to determine that the process is busy with network operations and generate an interrupt from the network card strictly on this processor, which significantly speeds up processing at speeds higher than 1-4 Gbps. Furthermore, inside each worker, there is a loop – an infinite cycle of calling the input and output fee. These f-groups are grouped into a dap_events_socket object, each such object (more precisely, a pseudo-object) has a particular connection: C–0, C–1 ..., it also has an implementation – on the schema from different dap_events_socket to drag the arrow to dap_http_client which does operations type request/response that does not require a permanent connection, or other arrows – dap_events_socket which has a dap_stream implementation. dap_stream ensures the permanently existing session between nodes, it drives data that requires speed, for example, network traffic of VPN services or new blockchain element of participants, or audio-video streams, anything. Each type of such data goes through its own channel – CH–B for example for blockchain elements, CH–N for VPN's network data and so on.

All these channel packets are grouped within the stream packet, which respectively goes through the UDP transport picked up by the dap_events_socket which is spinning inside the loop and reads the I/O from the remote connection that is inside the worker thread belonging to the individual processor.

The implementation need

Fact is that in modern multitasking systems the loss of computing power exponentially grows at high loads, which takes place due to the switching of processors between tasks and also directly to the input-output operations themselves. In such a scheme (as in the picture), I/O is grouped in one place, and processors group the I/O operations and subsequent processors and all the time are on the same processor. That excludes the switching back and forth, and at high loads, it is essential. Actually, without this technology, pumping even a Gb of data is difficult, and more than 4 Gbit is unrealistic at all.

Transaction Structure

This is a scheme of processes going inside of every transaction.

The beginning is a statement of a balance from the other Cell, verified by at least three randomly picked up Master Nodes or verified copy of token from ZeroChain. So if a transaction goes to another Cell, the outgoing transaction is verified by Master Node of sender’s Cell when the income transaction of receiver is verified by the receiver’s Master Node. Like one bank’s client send funds to the client of another bank. Each transaction should have at least three outputs – one for the receiver, one for commission (could be zero) and one for change. Outputs also could be open not only for the address but also for one-time keys, signed with closing ring signature – Zero Knowledge transactions.

ZK Ring Signature

Zero-level (Zero Chain) consensus

On the zero chain level, we check only one consensus: Proof-of-Genesis.

It works as a modified PoA: the first block holds only the one datum with general metadata and set of the root public keys. Every datum following the genesis block must be signed with the root key (genesis block keys).

Every next block must be signed with half plus one of the root keys number, e.g., if we have eight root keys in genesis block, we must sign every next block with any five keys random selected keys.

Sharding

Proposed sharding technology is breaking the whole blockchain into specific “shard chains” shards (Cells). These shard chains are composed in such a way, that all the same account information is present within one shard chain. The shard could be limited with size, for example, 1Gb.

Sharding will be tied to the topology, and the topology, in turn, is tied to the real network infrastructure. Accordingly, the hit in the desired particular shard is determined by default by its network proximity. If desired, you can define shards by yourself or request to make a new one by default. However, overcrowded shards may refuse new members to register. All requests for shards occur through messages inside the zero level blockchain.

All the shard events happen in two stages: Declaration and Announcement with at least X blocks between it. For Cellframe it means minimum time 10’000 seconds (could be more if the network is not loaded).

The declaration could be sent by Master Node or by Root Node. So if somebody wants to beсоme a Master Node, he has to send the request to any Master Node mempool and then it will be presented to the root nodes.

Root nodes check if the Master Node Candidate has held enough coins, closed with the specific output – Hold Output. It can be unlocked only with Zero Chain consensus. If the Candidate is good, then after X blocks Master Node Announcement with its public key declaration (related to the cell ID) should appear.

Cell Declaration works the same way, but such requests can be sent only by the Master Node that is already presented in the list. It must point to the cause of sharding – overloaded shard for previously launched Cellframe shard or coins held. Plus some metadata as usual. After all of the checks, root nodes announce the new Cell ID, and after that, the new Master Node Declarations would be accepted.

Inside the cell, there are two parts – Cell’s Base Chain and Plasma DAG. Cells' Base Chain is similar to zero chain: it stores verified balance states from other chains, where the next transactions could be placed only in Plasma.

Communication and Network Protocols

All communications are performed with the usage of the DAP SDK framework, an event-driven system, that gives an ability to process a lot of I/O operations in one thread. It starts by default the thread number equal to CPU count and assigns them exclusively to processing cores. The same technique is used by the popular web server Nginx that gives it a huge amount of same-time connections processed and served. We expect to have the same profit.

Key Exchange Connections

Cellframe starts every network activity from the public key exchange connection. First, a client connects to the server and receives the public key, signed with the particular key included to Cellframe whitelists. Client validates the key, and then sends a short message encrypted with a server’s public key. Then the server decrypts it with its private key, encrypts the answer with a client’s public key and sends the result back.

After entering the exchange, the client can easily initiate any Request-Response session or bring up the stream connection. The server produces the private symmetric SALSA2012 key for the stream connection to reduce the processor’s load. Moreover, once in 30 mins, the key is being changed.

Encryption with PQ–algorithms

To sustain variability principle, a 2-byte ID is added at the beginning at every spot for encryption. We expect that humanity will not invent more than 65’536 digital signature algorithms. For the beginning, we’ve selected the most perspective PQ algorithms: NewHope, NTRU, Frodo, SIDH* and others. One of the most interesting algorithms that we use is the Picnic — a Zero Knowledge Post Quantum signature. By default we use Crystal-Dilithium digital signature.

Also, a combination of more than one algorithm would be available; e.g., a user could close all the deposits in his wallet with more than one key (Multi-Algorithm Signature). The Strongbox is more secure when it's locked with more than one key.

Mirroring = Blockchain Insurance

Tokens

The zeroChain does not require token implementation for successful operation as it is based on proof-of-Genesis consensus and there is no mining in a traditional point of view. All decisions regarding block formation are made by initially authorized nodes and this chain stores only necessary technical information and does not store address balances, so it does not affect the security of launched Cells. All significant interactions in the network occur inside the Cells and in case of inter-cell communication. such as asset transfer operations are conducted via the p2p approach only and therefore not required to add additional records on zeroChain. Each cell is a pseudo-independent chain that is included in the overall ecosystem by inter-cell interactions. Thus, each network has its own consensus based on flexible POS (or DPOS/POA if required) that can be configured if necessary by a chain initiator. But Cells inside of a single network have a single type of consensus. Cells provide two main token functions: first is a stake for participation in consensus (for POS consensus) and second is the value transfer unit/unit of account inside the ecosystem (including inter-cell interactions).

The token emission process is as follows:

1. Root nodes receives a token creation request.
2. Nodes check if the author request has enough rights for token emission, and in the positive case, they publish the token declaration.
3. The token declaration contains the signatures of emission holders, which then allows them to add events to the emission of a token through the memory, and then publish a basic transaction with this emission to a convenient Cell. Important: the emission in the zeroChain is tied with the address, not the key and not the Cell.
4. At the moment of the emission, neither the key of the emission holder nor his shard is known until he wishes to use the funds and form the basic transaction in any Cell. There is a similar process when you transfer tokens from Cell to Cell — the basic transaction in the new Cell points to a transactional token indicating the plasm chain ID, Cell ID, and hash of transaction, the output of which points at the address signing the basic transaction.
5. Thus, the transaction between Cells has an atomic swap “under the hood” and it is slower than transaction inside the Cell.

Conclusion

In this paper, we demonstrated the principal tech features and execution paths. The protocol structure is proposed to be a zero level layer for blockchains and distributed systems because it can solve several existing challenges in the space: scalability, security and flexibility. Cellframe is capable of providing modifications to solve any future blockchain problems without harming the scalability or performance.

This paper will be extended with time with a more detailed description of interchain interactions, use case architecture, test results, etc.