At this point in your crypto-journey you may have come across the concept of scalability. The great majority of projects nowadays are working on it, so if you haven’t yet heard of or need a quick refresher:
What does ‘scalability’ mean in the context of blockchains?
“[T]he amount of transactions a blockchain can process in one second is known as the speed of the network. Scalability determines how easily a blockchain network can expand/increase ‘its speed’ without creating delays in processing more transactions.”
Now whenever you read or hear about “scalability” in Telegram, Facebook, a Medium post or discussed by your favourite “youtuber”. You can reference the above statement.
Scalability is an essential issue that needs to be solved if we want to live in a time where blockchains are adopted and used widespread.
The current issue with scalability is that, although many projects are trying to solve the lack of it in distributed ledger technologies, the way most of them are trying to do it follows similar philosophies.
They try to ‘improve’ the blockchains by maxing out the TPS of on-chain transactions. By sharding, faster consensus algorithms, etc…
Ok but… what’s the problem with that?
Well, on-chain transactions are limited by their own inner workings, namely the consensus mechanism that has been coded into the blockchain to aid in reaching a decision/consensus to verify transactions.
You’ve probably been on a date or have been to an outing with a group of people, so you can relate to the impending difficulty in arriving at a consensus when making decisions as the group size increases.
When it’s just 2 people, and you’re trying to decide where to eat, which is generally a pretty quick decision, what type of food and where to eat.
The conversation is usually along the lines of “So, what would you like to eat – any preference?” The other person would say something like “I’m really craving Japanese food, does that sound good? And so on until an agreement is made.
When the group increases from 2 to 20 people, for example, let’s see how easy it is to arrive at a quick decision when deciding where or what to eat. There will probably be long conversations and several disagreements before a final decision is made.
This is the same process that “on-chain” consensus mechanisms tend to follow in reaching an agreement when processing transactions.
In fact, in blockchain terms, the consensus algorithm needed between nodes in on-chain transactions is going to happen at the speed of the slowest node. As the blockchain grows, this consensus could take longer and longer – i.e. as the chain grows, unless the blockchain is highly scalable – transactions will slow down
On the other hand, they are already different protocols that focus on working off-chain, to increase scalability and other blockchain features. These protocols also suffer from different tradeoffs that we will see and are self limited within their ecosystems.
Enter Celer Network.
Celer takes a different approach to scalability — a new approach that others have not taken before. Celer Network is developing a platform which will provide unprecedented performance and flexibility.
Scaling by innovating off-chain techniques and incentive-aligned crypto-economics; they are aiming to accomplish up to billions of transactions per second, due to its nearly linear scalability solution (the more nodes and applications are running on the off-chain platform, the faster the network becomes)
What are off-chain transactions? A simple explanation:
“The movement of value outside of the blockchain, without the need of applying a consensus algorithm.”
Also, in order to guarantee their sustainability and their adoption in the crypto-space, they are building an “easy to develop” off-chain dApps framework to make it easier for project developers to focus on their own tech, not needing to deal with the problems of creating off-chain dApps.
Celer, and the full space, is moving at the speed of light. If you want to stay tuned and keep up the rhythm, you need the best info.
Get our free investment thesis
Sign up to get our exact investing strategy, start to finish. It includes our philosophy at Coin Crunch, as well as our top long-term picks.
To fully understand the impact of this revolutionary project, we must comprehend what they are aiming to solve in depth. We can name two different fields that need different solutions.
Three common problems that are usually found between on-chain based projects:
This has already been explained above.
It is easy to understand that, whenever a blockchain is open and every tx is confirmed and recorded within the blockchain, privacy is compromised. Except for those projects specifically designed to be private. A difference appears when we talk about off-chain transactions, because like in some cases we would say:
“What happens off-chain, stays off-chain”
On the other hand, we find; Problems common to current off-chained projects. Such as:
3. Developing, operating and interacting with Off-chain Dapps:
While doing so within on-chain project is something most developers do, when it comes to doing it over an off-chain protocol it is not easy at all.
That’s what creates problems for those off-chain protocols to acquire dApps in their ecosystem. Which in the end could limit their adoption and permanence in the crypto-space.
The chain provides the developer with all the information that is needed to work with that chain leaving the developer to not only create the interface between the blockchain and dApp but also handle the transaction security AND the interface for the user of the dApp.
This takes the developer a tremendous amount of time, not only are they focused on the user interface but also on the security and the details behind each and every transaction.
It also means that EACH developer needs to do this same activity for each and every dApp that is created. This could add up to a crazy amount of hours for the developer where they are essentially doing the same thing over and over again.
In the traditional programming world, one of the groundbreaking improvements that has sped up development time and improved the overall security of the application was the creation and use of APIs.
Not only do they obfuscate the details of the functions happening behind the scenes for the developer but they also ensure that the bugs (mistakes) in the code do not hinder the experience for the person using the application.
In blockchain, the maturity of most blockchains has not reached this level of usability.
Last but not least, off-chain projects have several tradeoffs.
While gaining scalability, an off-chain platform is also making tradeoffs on network liquidity and state availability. scalability-liquidity tradeoffs and scalability-availability tradeoffs will be discussed in the coming sections.
As we can see in the table, there are a few projects that are already trying to solve scalability by using off-chain technology.
Celer’s innovative approach to scalability starts with them being the first off-chain network solution that is the first in the space to be completely blockchain agnostic .
This is huge and potentially makes it an adaptable, limitless solution capable of working with many blockchains and alongside many on-chain and off-chain scaling solutions as well.
Of course, transacting off-chain directly increases the users privacy, making only the final state of the channel visible and recorded on the blockchain.
By horizontally scaling off-chain, Celer potentially can process billions of transactions per second, totally decentralized, secure, private and autonomous using their layered architecture – here are some of the innovations I want to briefly mention:
- A channel suite for developers that supports generalized off-chain dApp transitions beyond simple transactions, sidechain like channels that support minimal fund lock-ups
- A provably state routing algorithm with 15x higher transaction throughput than state of the art solutions.
- An off-chain operating system that simplifies the development and usage of off-chain applications on various platforms. With cOS, Celer is creating the framework were every developer can built his own applications in a simple and easy way.
- Celer provides a set of APIs so the developer can focus on the application and user interface
Also Celer Network has one of the most well thought out crypto economic structures we have seen among the many ICOs we’ve analyzed, which positively incentivizes “hodling” and community engagement through the Celer token.
We’ve created a special section called: ‘Special Incentive Model’ which goes into greater detail into the crypto economic structure of the network.
Tech and features
As we can see in the diagram, cStack has been developed to be blockchain agnostic, and therefore it can be used to implement nearly any blockchain. cStack tech is composed of:
- cChannel: generalized state channel and side-chain suite.
- cRoute: provably optimal value transfer routing.
- cOS: development framework and runtime for off-chain enabled applications
Each of these technologies is quite interesting and involved by themselves, together they advance the current state of what blockchains can achieve.
In this section below we will explain each area of the tech one by one to provide insight into what it is and a bit of the background on how it helps the Celer Network to operate so efficiently.
As stated above it is a generalized state channel that is implemented on the blockchain.
Exactly what is a state channel and what are the benefits of using this off-chain approach?
First, before discussing the team’s implementation we will provide some background on state channels.
A state channel is a 2-way discussion between users or users and a service. Each of the messages are transactional:
For example, I would like to get a haircut for $25.
Each of the messages are signed by both parties. The transaction is executed off-chain and once I get the haircut and pay the $25 to the provider the state channel is closed and the final result is written back to the blockchain (signed).
In this case, my account is debited $25 and the service provider’s account is credited the same $25.
The reason for implementing it this way, is that off-chain transactions are low cost and execution is very quick.
If this transaction was performed entirely on-chain. We would need to wait for the blockchain to confirm each of the transactions. Using the state chain transactions are nearly instantaneous and only the final transaction (is what needs to be written to the blockchain) is what we need to be confirmed.
To go back to our earlier example; when determining which restaurant to eat at with 2-people.
The 2 people are essentially opening a state channel (although you would never say this to your partner), determining which restaurant (the transaction) and then they have the choice of closing the state channel and writing the ‘choice’ to the blockchain or keeping the state channel open to then decide on where to go for drinks afterwards, and so on.
So, how did the Celer team implement this concept?
They had several design goals in mind in their design. The solution had to be:
- A fast, flexible, trust free solution for off-chain transactions until the final resolution
- A blockchain agnostic platform that could run on different chains that support smart contracts
- When possible, provide an efficient on-chain solution
To implement this, the team provided developers with an API.
The breakout of their functions as defined in the Celer Network white paper and subsequent blog posts are below:
- ResolveStateProof – This function updates the current state proof by resolving attached condition groups.
- GetUpdatedState(sp, s0). This function is used to get the most updated state based on off-chain state proof sp and on-chain base states s0.
- UpdateState(s). This function allows on-chain updates of state channel’s currently resolved states.
- IntendSettle(new sp). This function opens a challenge period before the settlement timeout. During the challenge period, this function takes a state proof as input and update the current state proof if the input is newer.
- ConfirmSettle(sp). This function validates and confirms the current state proof as fully settled given the current time has exceeded the settlement timeout.
- IsFinalized(args) and QueryResult(args) are the entry points for resolving conditional dependency. It accepts outside queries with necessary arguments for the querying contract to interpret accordingly. In fact, some patterns are used frequently enough, in cChannel’s implementation, we separate them into pre-defined function interfaces.
- CloseStateChannel(s). This function terminates the life cycle of the state channel and distributes necessary states (e.g., account balances) out according to the latest settled states.
The team also provided several utilities to assist the developer in creating dApps. These are:
- Off-chain address translator – helps map off-chain references to on-chain references.
- Hash Time Lock Registry – this helps multi-state transactions to take place atomically.
There are also three out of the box features that are a part of the Generalized Payment Channel (GPC) utility:
- Dynamic Deposit and Withdrawal– this provides the functionality to handle the on-chain settlement of a payment when the counterparty is disconnected from the Celer network
- Boolean Circuit Condition Group – this function defines the conditions for when a particular state should be triggered
- Fund Assignment Condition Group – this function can check the state of an off-chain transaction as well as other statistics about the transaction (how many restaurants were visited, etc)
Together they provide the functionality that we described in our haircut and choosing a restaurant examples.
A network of cGPC to enable “Internet-like” easy of use
Building off-chain dApps can be challenging, even though they encourage great scalability.
The complexity of interacting with conditional state dependent graphs hints to the necessity for a dedicated development framework. Here is where Celer integrates another giant step in their project.
cOS, which is the combination of application development framework (SDK) and runtime system developed by Celer. cOS makes it easier for dApp developers to operate and interact with the off-chain network of Celer, allowing more attention to be paid to the user experience of the dApps.
Celer Network categorizes decentralized applications into two classes:
- Simple pay-per-use applications
- More complex multi-party applications.
Orchid Protocol is an example of simple pay-per-use app, where the user keeps receiving microservices from a real-world entity and streams payments through the payment network.
By putting Celer Network’s lean transport layer API on top of the routing layer there would be no need for conditional dependency on other off-chain states.
Structure of dApps on Celer Network (cApps)
On the other hand, the idea of conditional state dependency graphs really shines when we talk about multi-party applications, whose general structure is shown on the image above.
The SDK defines a set of design patterns and a common framework for developers to express the conditional dependencies. It also provides a code generator that generates a set of “bridge methods” for interacting with smart contracts whose code is available at compile time.
The cOS runtime will serve as the interface between cApps and the Celer Network transport layer. It helps the applications in local off-chain state management terms and network communication.
cOS Runtime Architecture
In a simple way, cOS handles the following task by becoming a complete toolchain solution for the creation, tracking, and resolution of states in off-chain applications:
- The tracking, storage and dispute of offchain states
- It buffers intermediate node failures transparently
- Supports multiple concurrent off-chain dApps
- Compiles a unified implementation to different on-chain and off-chain modules.
- Figure out the dependency between arbitrary off-chain and on-chain states.
cRoute: Provably Optimal Value Transfer Routing
All existing off-chain payment routing solutions use the “shortest path routing”.
This could potentially create poor performance due to differences in the link model. Link model in an off-chain payment network is stateful.
As a result, in a busy network, links are always changing and makes the shortest path routing impossible. So the network slows down.
cRoute introduces Distributed Balanced Routing (DBR) which manages payment traffic by using distributed congestion gradients.
The main properties of the DBR are:
- Probably optimal throughput. DBR achieves 15x higher throughput and 20x on higher channel utilization ratio compared to anything state of the art solutions existing.
- Transparent Channel balancing. Balances the channel without any additional coordination.
- Fully Decentralised. DBR algorithm only needs to talk to its neighbouring nodes in the state channel network. It also has low messaging cost.
- Failure resilience. DBR has built in scan and detect unresponsive nodes. This keeps the remaining available nodes at maximum throughput.
- Privacy preserving. The multipath nature of DBR preserves privacy regarding the amount transferred value without any additional feature.
‘Special Incentive Model’
Now that we have seen the interesting technology that Celer has implemented – its time to understand another feature of the chain – its special incentive model.
In other blockchains there are a few ways to incentivize people as they assisting the blockchain in approving transactions on the chain. This could be via a variety of consensus mechanisms including mining, proof of stake (wallets and masternodes) and other unique solutions.
As Celer Network is an off-chain solution they had to develop a solution that would avoid some of the challenges that come with off-chain solutions. Those 2 cases are:
- Scalability vs Liquidity
- Scalability vs. Availability
These generally go hand in hand and you cannot have one without the other.
They would need to solve these cases to keep the chain running optimally without delays
As a part of this solution they have recognized that those with sufficient funds can assist but may not have the business interest or the technical expertise to contribute their funds and conversely, those with the technical skills may not have the funds to maintain a highly available service.
To cope with this, Celer Network has developed a suite of cryptonomic mechanisms that they are calling cEconomy, that involve their token, ‘CELR’.
The cEconomy has 3 mechanisms that aid the incentive process.
- Proof of Liquidity Commitment (PoLC)
- Liquidity Backing Auction (LiBA)
- State Guardian Network (SGN)
Each one of these contributes to the token economy in their own way.
Main Features of Celer Network
In the main features we want to focus specifically on the cEconomy and the three mechanisms that make it up.
The cEconomy is centered around the CELR token, the currency that the Celer ecosystem runs on. The tokens utility is made clearer when we look at the three mechanisms that make up the cEconomy
1. Proof of Liquidity Commitment (PoLC) mining
A virtual mining process that creates a liquidity pool, equipping service providers with a necessary flow of funds when needed.
This is done through the Network Liquidity Backers (NLB) locking in their tokens on the Celer Network for an extended period of time and rewarding them with more Celer tokens, hence creating the above mentioned liquidity pool with built in stability.
2. Liquidity Backing Auction (LiBA)
Off-chain service providers on the Celer Network are given access to liquidity no matter where they are in the world through ‘crowd lending’.
By starting a LiBA on the Celer Network, an off-chain service provider can be funded/given the necessary liquidity by borrowing the funds (CELR) from a willing contributor on the network.
Similar to a bank loan, the crowdsourced liquidity backer will submit a bid with the interest rate, the amount of liquidity they can provide, the amount of CELR they are willing to stake for the allotted period of time and then the funds are sent to the Collateral Commitment Contract (CCC) to be managed.
3. State Guardian Network (SGN)
Is a compact side chain that monitors/guards off-chain states when the users are offline. CELR tokens can be staked into SGN to make the token holder a State Guardian.
So before a user goes offline, they can submit their state to SGN and for a specified fee can have their state guarded by the guardians for a period of time.
To learn more about Celer’s unique cryptoeconomics, please see our in-depth video explanation here:
To be announced shortly!
Dr. Mo Dong – Co Founder
- Dr. Mo Dong has 3+ years as an Engineering Team Lead and Product Manager at Veriflow.
- He was a founding employee.
- Lead an all Ph.D team on highly scalable core Network Formal Verification Algorithm design and distributed system infrastructures of the product.
- Notable stint was 4+ years as a Research Assistant at University of Illinois, Urbana-Champaign.
- He has a short stint 4 months as a Member of Technical Staff Intern at Nicira in Palo Alto (silicon valley) and had 2 patents by the end of his stay.
- Ph.D, Computer Science, 4.0/4.0 at University of Illinois, Urbana-champaign.
- His Ph.D thesis research was to rethink the 30 year old architecture of internet protocol TCP, to achieve consistent high performance and low latency data delievely.
- Now he has the hunger to work on distributed system and the networking side of blockchain technology.
- B.S, Electrical and Electronics Engineering, 3.76/4.0 at Shanghai Jiao Tong University.
Dr. Junda Liu – Co-Founder
- Dr. Junda Liu has accumulated 6+ years as work experience at Google. During his years he is obtained a guru level of coding Python, C++, bash. OS – Linux, unix. Deep knowledge in Distributed Systems, Algorithms, Cloud Computing and Machine Learning.
- Google work history:
- He started at Google in Aug 2011 – Mar 2013, as a Software Engineer where he focused on everything about inter-dancenter networks and datacenter.
- April 2013 – April 2014, as a Senior Engineer in Platform Networking team. Where he was the Tech Lead of Google Jupiter data center fabric topology flexible & efficient network for large scaling centralized control
- Recently He held the position of Senior Engineer in Android team where he worked with Android Carriers APIs and services.
- Dr. Liu’s education has a full stack of academic degrees.
- PhD, computer networks at University of California, Berkeley.
- Attended University of California, Berkeley – Walter A. Haas School of Business.
- MS, Computer Science at Tsinghua University.
- BS, Information Theory also at Tsinghua University.
- He also has been part of 3 publications:
- Libra: Divide and Conquer to Verify Forwarding Tables in Huge Networks.
- Ensuring Connectivity via Data Plane Mechanisms
- Bridging the Software/Hardware Forwarding Divide
Dr. Xiaozhous Li – Co-Founder
- Dr. Xiaozhou Li has a mix of 2+ years in Software Engineering and 5+ years in Computer Science work experience. Specialising in developing scalable algorithms and protocols that achieve higher performance at low cost. Major systems in this field that has been widely adopted include Google TensorFlow, Intel DPDK and Barefoot Deep Insight.
- Notable previous roles:
- Software engineering at Barefoot Networks. Where he worked on :
- Intelligent data, computing to accelerate
- Distributed applications
- Design for next gen programmable switching ASICs
- Research Assistant at Princeton University. Where he worked on :
- High performance and cost-efficient key-value storage.
- Scalable and fault tolerant data center Multicast
- Large-scale 3D virtual world platform
- Software engineering at Barefoot Networks. Where he worked on :
- Short stints at major organisations as a Research intern/Assistant, Microsoft Research, Intel Labs and University of Pennsylvania.
- Dr. Xiaozhou Li has a Full stack of academic degrees:
- Ph.D, Computer Science at Princeton University
- M.S.E, Telecom & Networking at university of Pennsylvania
- B.S, Electronic Engineering at Tsinghua University
- He also has 2 major awards:
- NSDI’18 Best Paper on the topic “NetChain: distributed coordination service at line speed” at USENIX, the Advanced Computer System Association.
- Sibel Scholar at the Siebel Scholars Foundation. This foundation recogniszes the most talented students at the world’s leading graduate schools of business, computer science, bioengineering and energy science.
Dr. Qingkai Liang – Co-Founder
- Dr.Qingkai Liang main work history has been in as a Research Assistant for 4+ years at MIT Laboratory for Information and Decision Systems (LIDS) located in Cambridge Massachusetts. Studies focused on Robust Learning and optimization of networked systems. Some of his projects where:
- Optimal Networking control and learning in adversarial environments.
- Provision of Quality-of- Protection for wireless networks
- Design of ultra-low latency datacenter networks.
- He also had short stints at Google as a Software Engineering Intern, where he was in the Platform/Infrastructure Network Team, Nokia Bells labs as a research intern where the focus was on Mathematics of Networks and Complex Systems.
- Every team member here is stacked with full set of academic degrees:
- Ph.D, Computer Networks, 5.0/5.0 at Massachusetts Institute of Technology.
- BE, Information Engineering, 93/100 at Shanghai Jiao Tong University.
- He has 5 major awards.
- Best Paper Nominee at IEE Mascots 2017.
- Best-in-Session Presentation Award at IEE INFOCOM 2016.
- Ho-Ching and Han-Ching Fund Award at MIT 2014.
- Excellent Bachelor’s Thesis Award at Shanghai Jiao Tong University 2013.
- Excellent Graduate Award at Shanghai Jiao Tong University 2013.
Dr. Christos Kozyrakis – Technical Advisor
- 15+ years as a Professor of Electrical Engineering & Computer Science at Stanford University. He lead a research group that investigates hardware architectures, runtime management environments, system software and programming models for system ranging from cellphones to warehouse-scale data centers.
- Full stack of academic degrees;
- Ph.D and Master’s Degree, Computer Science at University of California, Berkeley.
- BS, Computer Science at University of Crete
- 18 Publications and 1 Patent – Low Power Programmable Image processor, Issued Sep 21, 2014: US 14/492,535.
Dr. Alan Mishchenko – Technical Advisor
- Dr. Alan Mishchenko has 20 years experience as a Research Engineer at all levels and all at UC Berkeley. His other stop was at 4+ years – Visiting Scientist at Portland State University.
- Ph.D, computer Science at Glushkov Institute of Cybernetics, Kiev, Ukraine
- M.S, Applied Mathematics and Information Technology at Moscow Institute of Physics and Technology, Moscow, Russia.
Dr. Shoucheng Zhang – Advisor
- Dr. Shoucheng Zhang has been a professor at Stanford university for over 24+ years.
- Graduated with a Ph.D, Physics at SUNY stony brook.
Where can I learn more about Celer?
Please check out their MVP demo showing the most advanced full stack off-chain solution. They will release code and a roadmap soon.
Get our free investment thesis
Sign up to get our exact investing strategy, start to finish. It includes our philosophy at Coin Crunch, as well as our top long-term picks.