Tokenization of payment channels and roll-ups. ENVELOP (NIFTSY)

7 min readSep 9, 2021

Disclaimer — perhaps this time you should be aware: the material has a number of simplifications and assumptions, each of which requires a separate and very detailed analysis. Nevertheless, we, the team (founders, advisors and active members of the community), should outline the boundaries of the architecture of the super-DAO NIFTSY (Protocol + Oracle + Index + Token), and than later we can bring it closer to the details and explain specific elements. Therefore, get ready for an exciting, but very difficult adventure!

Channels and roll-ups — what’s the difference?

Let’s first take a look at what exists today

https://lightning.network — “a payment protocol that operates over blockchains (usually Bitcoin is used). It does instant transactions between participating nodes and is proposed as a solution for the scalability problem. ” The statistics can be viewed below (however, we took the average version: the maximum indicator provided by the https://1ml.com service is 24,085 nodes). Taking into account that the concept was born in 2015–2016. and was implemented in 2016–2017. (unless, of course, we go deeper: the general message was formulated back in 2009–201 … and it can be found, say, in Satoshi) — growth is quite promising in the term of next 5–10 years. For a detailed understanding we recommend the self study of the following parameters: the growth in the number of blocked coins (BTC in particular), the growth in the number of open channels, and the capacity of the channels. If you do not want to do self study today, then wait for the next material with a breakdown of numbers.
https://plasma.io/plasma.pdf — Lightning Network for Ethereum, or more precisely, “Plasma consists of two key parts of the project: revision of all blockchain computations into the MapReduce feature set, and an optional Proof-of- Stake token binding method. ” It is extremely important to note that the connection between small chains and the main chain is protected by fraud-proof, therefore the main chain is responsible for security and a prevention from intruders (through punishment). The Plasma whitepaper presents the interesting application of the so-called MapReduce calculations — a set of functions those are very useful for organizing and calculating data in several databases, but in the context of Plasma, these databases are blockchains, and “the tree structure of the chains uses MapReduce in a way to make it easier to verify data within the tree chains, which greatly improves the efficiency of the network. “
https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/ — if we talk about roll-ups, then Optimistic & ZK roll-ups are a must have for studying. You can immediately refer to their comparison. Roll-ups are “solutions that execute transactions outside the main Ethereum chain (level 1), but place transaction data at level 1. Since the transaction data is at level 1, roll-ups are protected at level 1. Inheritance of the level 1 security properties while performing transactions outside the level 1 is a defining characteristic of roll-ups. Roll-ups require “operators” to post a deposit to the roll-up contract. This encourages operators to validate and execute transactions correctly. ”

For more details, there are several examples:

Before to continue, let’s have a look at the statistics.

Problems. Transactions

One wise guy somehow decided to collect all the pros and cons of Ether with a post and did it: https://twitter.com/RyanSAdams/status/1344461378921365506. But since then, many questions have been raised.

One of them, which should be asked by everyone who dives into the issue of channels, sounds simple: “why do we need channels if ETH2 is already PoS?”. And really: why? The speed will be decent anyway, the issues of scaling due to sharding (let’s admit it and accept it as an alleged fact) can also be eliminated …

And why then all this?

This question can be answered as follows:

“There are two aspects: first, channels can be tokenized; secondly, they, like roll-ups, create add-ons outside the main network and thereby customize the needs of the business and / or user ”.

Let’s clarify these two aspects.

Let’s take MEV — “a rate of the profit that a miner (or validator, sequencer, etc.) can get due to its ability to include, exclude or change the order of transactions at its discretion in the blocks they create”.

So what? This means that if we want to minimize the risks from various attacks within the network, we must … get out of this network. In that case how to utilize the advantages of DDS (decentralized and / or distributed systems)?

The easiest way is to create your own channel (roll-up) and interact within it with other businesses, as well as consumers, minimizing attacks from various Super Nodes.

At the same time: proofs in ZK-format allow one party (verifier) to prove to the other (verifier) that the statement is true, without disclosing any information other than the reliability of the statement itself: “for example, having received a hash of a random number, the prover can convince the verifier that the number with such a hash value actually exists, without revealing what this number is. “

That is, if something happens in the channel, it is not necessary for everyone outside to know about it: it is enough to send there only a certain approved and verified (again, via ZK) list of data. Including: about the closure and / or blocking of the channel, about the entry / exit of new members, etc.

At the same time, we should consider one more important feature: “Zero disclosure proof is a probabilistic proof, not a deterministic one. It must have three properties: completeness, correctness, and zero disclosure. The latter property implies that any Verifier does not learn anything from the proof except the very fact that the statement is true ”- therefore ZK-mechanics play a dual role: on the one hand, they protect the channel from external influences, on the other, with each new iteration outside — make it more and more secure.

If you want to dive into the world of ZK, then the Wiki will not be enough, and therefore — here’s a set from which to start:

zk-SNARKs at its best:

https://arxiv.org/abs/2008.00881
https://www.di.ens.fr/~nitulesc/files/Survey-SNARKs.pdf
https://eprint.iacr.org/2013/879.pdf
https://dl.acm.org/doi/10.1145/2090236.2090263
http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf
Bulletproofs protocol: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf
ZK vs (post) quantum cryptography (and inside it): https://eprint.iacr.org/2018/046.pdf
Now, briefly, what NIFTSY does in terms of tokenization of payment channels and roll-ups.

ENVELOP, or the next level

First, Uniswap & 1inch (and not only them) switched to Optimistic, but these solutions are used only to optimize transaction costs for the project itself and its participants so far. What about the main goal of all DAODEX, including DeFi, projects — with liquidity? It remains locked, yet.

This is where tokenization comes in:

Create a channel (roll-up).
It has an irreducible threshold of liquidity introduced (more is possible — less is impossible): everything is like an accumulator in NFT.
NFT is emitted for a given (minimum) liquidity and this asset is moved outside.
Trading is done within the channel (until its termination close) and the NFT associated with it.

Obviously, security issues arise: first of all, the link of the working channel with the NFT.

This problem is solved at three levels:

Organizational: one of the NFT micro-DAOs becomes the channel administrator and controls the opening / closing / blocking process.
Technical: to destroy the NFT and / or reset the drive is possible only before closing the channel, while the channel can not be closed without “destroying” (burning / freezing) the NFT channel. This protection method is the opposite of what we have now. Today you have a unique ID-key (private) and while you own it, you can confirm the entrance, access and anything else. Immediately, only the destruction of the key can initiate the closure of the channel: but closure is not necessary, but only possible.
Economic: it is more profitable for liquidity providers to trade two financial instruments rather than one.

Schematically it looks like this:

This, of course, does not finish with tokenization, but before we move on to describing such processes, here are some recommendations for studying.

Important sources

So, since the article is introductory, we decided that it is extremely important to acquaint the reader with that minimal knowledge base (data) that can be useful in further immersion in the topic, since a number of questions are still in the field of theoretical study, there are only several, sometimes even mutually exclusive, practical implementations.

Of course, this documentation is not exhaustive or even generally recognized, but it will definitely help technical and, importantly, non-technical specialists to study the issue both broader (in the areas of integration) and deeper (regarding the mechanics of implementation through the NIFTSY Protocol / Oracle):

2013:

2014:

2015:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

2016:

2018:

https://github.com/ElementsProject/lightning

2020:

2021:

https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/

If you study this material in Russian and / or have sufficient translation skills, then dive into:

What will happen next?

Then we will try to consider simple questions that were somehow published by our colleagues:

How do nodes find each other and exchange network topology information (discovery)?
How is anonymity (onion routing) achieved?
How is data transmission between nodes encrypted (brontide)?
How not to download the entire blockchain for full node operation (neutrino)?
What is the structure of the invoice (payment-encoding)?
How to concisely store keys for canceling the status (shachain, elkrem)?
What algorithms are used to find the route of payment (routing)?

But before that, let’s try to take a broader look at payment channels and roll-ups and present them as entities that help, on the one hand, to avoid attacks on shared networks, and on the other hand, work inside an untrusted environment by creating a trusted segment.

Feel free to write all questions to the group: https://t.me/niftsy and

See you!