Nervos Nation & Tempest Labs — Telegram AMA

Introduction: Tell us your background and a little about yourself.

Hello Nervos Nation, thanks to everyone who is attending, and thank you to Kevin for facilitating.

As you know, I co-founded Tempest Labs along with a couple other brilliant folks. I have been working in the blockchain space for a while now, and have been working with Nervos technology for a few years — prior to the launch of the first testnet. Most recently, I worked on the core smart contracts team at MakerDAO, where I was primarily working on security and formal verification.

1. Why pick Nervos?

Nervos Network’s layer 1 chain — Common Knowledge Base (CKB) — are especially suited for the specific type of technology we are building. CKB’s fundamental state structure, referred to as a “Cell”, falls into a class of chains that extend the UTXO model introduced by Bitcoin. Of the other chains in this class, the Cell model is particularly flexible and expressive. So, what makes CKB the top choice then?

Well, we have to ask two questions when choosing infrastructure as engineers. The first question is: does the infrastructure prohibit, for some reason, our ability to build the system we have in mind? The second one is: even if it is possible, how *feasible* is it with one infrastructure versus another.

On many chains, account and utxo alike, the protocol we are building is practically impossible. On other top UTXO-style chains, while subsets of Tempest features are possible, they are, for all practical purposes, infeasible.

2. Why L1 vs L2?

This is a couple reasons. The first is that L2s in general are not appropriate at this time given the goals of Tempest. The goals of Tempest protocol is to be an extremely secure, safe, and easy to use infrastructure that can onboard millions of developers into the space (right now, there are less than 20K total devs in web3 I believe globally). The most straightforward way to do that is to stay on L1 where we have all the natural benefits of the L1.

Second, I think that generalized UTXO chains are actually underestimated in the level of “performance” they can achieve. Comparing, for example, the throughput of CKB to something like Ethereum doesn’t really make sense because a transaction comprised of UTXOs can represent a massive number of state changes in a single “step” that would take long sequences of transactions to represent on Ethereum. So, all other things being equal, you can design L1 dapps (at least on CKB) to accomplish a lot more in a single tx or block than in many other chains. Basically, I think we have only scratched the surface of L1s, so why move to an L2 and add complexity this early? It is premature.

Finally, after a lot of experimentation and research, it is clear that we actually need the Cell model at this time. So the only L2 that would work for us currently is one that had the same exact properties as the programming model offered by CKB itself.

3. I heard there is auto trading/investing function, is it something that can be used without much knowledge of day trading?

Yes, people will not need to be experts in trading or analysis, because the autonomous network will seek to achieve the end users’ goals on their behalf. Various trading strategies can be explicitly encoded as additional contracts that any developer can submit to the network.

As more dapps are built on Tempest, the Solver network will likely begin using more sophisticated approaches to generating profit for end users. This is a benefit conferred to all dapps built on Tempest, not just the DEX we are building.

Essentially, the DEX is a special “portal” or “view” into the network, exposing a subset of its capabilities that make sense in a DEX context.

4. How would Tempest Labs bring USDC, BTC, ETH etc. on Layer 1 of Nervos, will there be trading pairs and what will be the DEX coin?

Tempest does not specifically concern itself with any pairs — members of the ecosystem can certainly use Tempest to implement certain pairs, and if you submitted an order to trade between two tokens that are not “listed” in the DEX, the Solvers will try to find a way to support that pair so that you can trade. The “pairs” in the DEX, then, *can* be any assets that exist on CKB itself (though some pairs might not be great or easy to fulfill).

Unlike many other DEXes, where pairs are “approved” or “whitelisted” in some fashion, this is not how the dex works on Tempest. This is in part because, unlike many other platforms, we can encode security properties and requirements of other tokens within the dex contracts, and the contracts, combined with the solvers, will ensure these properties hold. So, we can make sure that, for example, only tokens with ideal properties are added as pairs in the dex, without requiring any sort of manual process.

Also, we are looking at force bridge & we are exploring potential support for various pairs upon or post-launch using the force bridge to inject existing tokens into the ecosystem.

Tempest will have its own token as well, which will be supported in the dex (as will CKB).

5. What is the strength of the team behind the project ?

We have some great people on the team. We are all aligned on the vision that we want more substance and less superficiality in the space. We all believe in long-term sustainability, and we all believe in thoughtful and research-driven development as opposed to hyperbole and false claims.

In terms of team members other than myself, we have a full time senior rust developer, Pablo, who’s been working in the blockchain space for a while, and has been in the Nervos ecosystem for around two years. Another full time member, Clint, is a fifth year PhD student in electrical engineering. He does a lot of work on mathematical modeling of stochastic & dynamical systems, agent based modeling & simulation, and financial engineering. Every economic decision we make is validated against a series of computational experiments to ensure our assumptions are well-founded. Another co-founder is Michael Deakin. He’s got an incredible mind for business, partnerships, and people. He’s a multi-time founder and currently runs one of the top recruitment firms in the space.

We also have a third co-founder who’s still in stealth mode. So all I can say about him is that he’s started and run multiple successful companies, served at a director/executive level on multiple blockchain projects (some of which are household names), and I can’t wait until he’s not in stealth mode so you all can talk to him directly xD

6. What actually makes the dex autonomous and during bear markets who is the liabillity?

I will answer what makes it autonomous, because I’m unsure what is meant by the second part of the question.

First, it is important to understand that Tempest Labs is building two projects in parallel: The protocol itself — which provides a way for anyone to run an autonomous agent that processes transactions — and a dex product on top of that protocol.

Think of the protocol as a “decentralized backend” for “autonomous” dapps; by building a dapp on Tempest, the dapp is inherently autonomous. What “autonomous” means in practice for dapps is that dapp developers need not write a bunch of code to implement their business logic. Rather, they need only declaratively specify their business logic, and the protocol will provide that functionality. We can think of this as a natural extension of “declarative smart contracts”. Recall that for UTXO-based chains, we get some nice benefits like determinism (the entire result of the transaction is known prior to processing that transaction). But we also have to deal with the fact that on-chain code cannot actually mutate state; it only checks whether the current contract is valid according to some set of rules defined in the contracts. So, dapps on UTXO-based platforms need software for generating transactions that get submitted to the chain, as well as verifying transactions that are processed by validators. The latter software is what we call “smart contracts” or, in Nervos Network terminology, “scripts”.

Because scripts merely *verify* rules, they lend themselves naturally to declarative programming.

Declarative programming languages enable programmers to specify *what* they want to happen as opposed to imperative languages that expect programmers to specify *how* the VM or computer should accomplish the task.

While declarative programming feels very natural in conjunction with UTXOs, declarative smart contract languages are actually feasible for any smart contract enabled blockchain — UTXO or not.

The difference with Tempest is that we extend the idea of declarative programming even further: the declarative language used to write smart contracts with Tempest is not only executed on-chain for verification, but it is also machine-readable to such an extent that transactions can be automatically generated based on the rules defined in the contracts.

This means that we can define a single interface for both transaction generation and verification. But even this isn’t good enough, so Tempest technology does more than merely compiling the declarative code to software that can build the transactions specific to your dapps… Such code would still have to be hosted on a server somewhere. It is still declarative and not quite “autonomous”, because it is your server, that you can modify at any time, and that follows any old rules.

Tempest takes it even further than this by actually providing a generic network — called the “Solver network” — that generates transactions for ANY system of smart contracts written in our language. Anyone can participate in this decentralized Solver network by running the Solver software.

The Solvers follow their own protocol and play their own game. They are designed to learn and improve their ability to generate transactions on users’ behalf.

The Solver network replaces the role of a server in a way. Users of various Dapps that are built on Tempest Protocol interact with a dapp via submitting their “goal” or “intent” to the Solvers, who then carry out the goal on users’ behalf. Thus, “dapps” are really just sets of possible behaviors written in our language and displayed in a particular front end.

7. What services are you providing to help others creating projects on Layer 1?

First, we are developing a fullstack development framework for CKB called “Trampoline”. It is under active development and is already open sourced. Trampoline massively simplifies and shortens the amount of time it takes to build a dapp.

Second, we are developing a declarative, logic based language called “Validity”. The reason for the name is that it is pronounced very similarly to “Solidity”, yet could not be more different in terms of its syntax and semantics.

Third, Tempest protocol provides revenue opportunities for open source developers who write Validity code on the network. This is all done in an automatic way. Such ongoing revenue streams for open source developers who build on the network provides entirely new type of business model for open source devs. Right now, open source development is only funded if you’re an employee at a company who cares about OSS, or if you apply for things like gitcoin grants or ask for donations/patronage. Many of these place the burden of finding the money on the dev, which is unfortunate in my opinion.

Finally, the combination of the above, alongside the Solver network, will enable devs to build dapps in a fraction of the time without undermining safety and security for end users. DeFi development is often under a lot of pressure to move fast and ship things. Such pressure discourages safety and security. Simultaneously, financial systems require far higher assurance than software like apps, games, websites, etc… traditional financial software, for example, is considered “critical software” which comes with many requirements in terms of correctness guarantees etc. Blockchain is too immature right now to have these same requirements (and theyre hard to enforce in a permissionless system), but this often results in massive vulnerabilities and poor quality code. So, we are providing a way to build high quality software in this space without falling behind, and at a fraction of the cost (auditing and security services can often cost a project millions of dollars annually).

8. What factors in your company impact byte lock-up? I’m aware that the value of CKB increases as the value/data on chain increases, but what’s considered value/data? What could run on L2 and never impact L1/CKB.

The beauty of the cell model is that code, data, assets/tokens, and anything else can be stored in a Cell’s data, and a Cell’s data capacity is limited by the number of $CKB in that cell (1 $CKB = 1 byte of storage). So, as the demand for any token on the network increases, so too will the demand for storage (since any token on the network must occupy space). Contracts also require storage, so development activity will also drive up demand for $CKB. Of course, this is good for us, since the increased CKB valuation is equivalent to an increase in the “security budget”.

Many things can be run on L2 using various cryptographic structures that act as accumulators on the L1. At this time, Tempest protocol’s has technical requirements that can only be met on L1. Of course, as demand for $CKB increases, we will continue to try and find ways to use the storage we have available responsibly.

9. What features of the project are made possible by the cell model and/or Nervos’ characteristics? Hearing about potential future developments would be great too.

The ability to enforce higher order properties in our contracts is purely due to the ability of a script to introspect the entire transaction. For example, you can write a script that enforces the rule that “the transaction is valid only if all of Token X is deposited into a vault that only accepts fungible tokens that have a capped supply”. Notice that the rule is in Token X’s script, and it is not ABOUT the Vault, rather it is about OTHER tokens that the vault might interact with in the future. These types of higher order properties enable a new level of automation that people have yet to achieve on other platforms.

So this type of expressiveness is enabled by the Cell model.

Another thing enabled by the cell model is safe composability. This is not strictly the cell model, actually, as much as it is the transaction model, which includes “dependency” fields that can contain Cells without “spending” those cells. We utilize this heavily, because it allows us to enrich the transaction with extra meaningful information (in other UTXO chains, the only way to get the UTXO into the transaction is to spend it — even if all you want to do is look at some data in the UTXO).

Finally, the virtual machine of CKB is low level enough that we have the power to implement a lot of custom logic and semantics quite naturally.

10. Will the work of Tempest Labs pave the way for more dapps on L1? (tools, frameworks, docs, etc.)

Yes. As mentioned above, we are building tools & frameworks (trampoline), programming language (validity), developer infrastructure (solvers) and are actively working on documentation, wikis, and tutorials both for Tempest specific tech as well as CKB in general.

11. What do you see as the main challenges for building on Nervos’ L1 — especially for developers coming from the EVM/Solidity space?

There is a tradeoff between power + flexibility and ease of use. CKB programming model is much lower level than what ethereum developers are used to, so it is a very significant transition from smart contract development on ethereum to smart contract development on CKB.

Further, it is so flexible, that it is not always obvious what the BENEFITS of switching are. To get someone to switch to new tech stack, it is not enough to be *as good* as the alternative, because switching costs time, effort, and incurs opportunity cost. So the switch has to be worth the cost. That comes from enabling entirely new possibilities, or providing drastic improvements.

I think that in general, we all know as community members that CKB enables entirely new classes of decentralized technology because of its flexibility — many of us here today have made that claim at some point. Yet, if you were asked: “What does CKB enable in a dapp that is actually impossible in Ethereum”, could you answer it?

For a while, even I couldn’t. It wasn’t until I was deep in the ethereum space and began formulating the idea of Tempest (which is meant to be a solution to a lot of the problems I witnessed first hand), that I had a very clear and explicit idea of the sorts of capabilities it enabled at the dapp level that were impossible on other chains.

So, I think that is the main challenge: coming up with a selling point for DEVELOPERS… CKB is harder to work with, it is lower level & takes more skill, AND it is foreign to devs used to ethereum… that’s a tough sell.

But hopefully the tech we are building at Tempest — which showcases multiple capabilities that have been impossible thus far — will be convincing enough :P

— — –

Nervos Nation Community Questions

Q. Thanks Tannr for such comprehensive answers. Will Trampoline allow easy creation of sUDTs with customisable features? I remember you shared a screenshot of this a little while ago.

A. Yes trampoline does have built in support for SUDT i interaction, deployment and extension :)

Q. It would be interesting to make some comparison in the future between solvers and batchers (for example the solutions that use Cardano’s DEXs). UTXO is continually accused of needing a centralized offchain solution to process transactions, for example for a Uniswap-style DEX. I think it would be an interesting debate that would give you visibility in the space.

A. Yeah, this would be interesting. I’ve read the papers each of the Cardano DEX’s include and they all have some form of batching. The main difference I see is that solvers are playing a specific “game” defined by incentive mechanisms and also they are generic in that they will construct any transaction, not just DEX-related.

Website: https://tempestlabs.org/

Twitter: https://twitter.com/tempest_labs

Subscribe: https://insights.tempestlabs.org/