The 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. The governments started using passports, identity databases, which collect almost every move of citizen and 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 went a long way. We saw the hype, devoted to 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 really smart contracts work and what are their technical limitations. The popular opinion is that “smart contract” = “secure, trustless system”. But it is not exactly true. And we are not only talking here about the 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 that many ordinary users are unaware of.
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, a properly executed attack can lead to a 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 is the limitations applied to business logic that can be implemented into a contract. Taking into account the 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.
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 opposite, 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 ownership and protection of end-user. 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 $150M 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 private key (note, that even if you have 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 areas of efficient, practical application. There are situations when a blockchain service cannot replace a smart contract due to fundamental reasons. For example, the leading case is the following: you need to create a dApp, business logic of which doesn’t rely on the installation of service nodes, 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 the necessity of running a certain number of physical nodes and maintain them is a crucial point of 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. Additionally, we use the combination of Blockchain and DAG chains in each shard. 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 too 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 an example of a product built on the Cellframe SDK we present KELVPN — a decentralized VPN focused on maintaining the privacy of user’s data and the provide secure Internet connection. You can download the client and test it here, or support this project and launch the VPN node.
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?
Instruction to launch a Cellframe node.
Telegram group where you can ask your questions directly to the CTO: https://t.me/cellframe