Scale blockchain while maintaining decentralization with Fairlayer
As many have already noticed, commissions in Bitcoin have been steadily holding around 10-20 bucks lately for a simple transfer.
This happens because the block size is limited to a constant value, and those who want to fit their transaction into a block are noticeably larger than before. What causes competition for the commission and its natural growth.
It is logical that by increasing the block we will be able to accommodate more people, which means to postpone the problem ? On the one hand - yes - so did Bitcoin Cash, the whole essence of which is to increase the block size to 8 MB.
')
On the other hand, no. About this, and about Fairlayer developed blockchain which elegantly solves this problem - under the cut.
I remind you that the only correct way to use cryptocurrency is to be full-value - otherwise you rely on the cartel of miners to follow the rules of consensus. Miners / validators need to maximize profits, and as soon as they feel the power, they will start banning unwanted ones, create unspent transaction outputs from the air, and so on.
Each node verifying each state motion is a guarantee of a decentralized and honest network. Recently it has become fashionable to say that simple payment verification is normal and that we somehow believe the miners that they do not double the special. We will not go into this - anyone can google why the maximum number of fulls is extremely important, and why the laptop should always be fully full, otherwise the network is centralized around state keepers, who at some point can simply stop distributing new blocks to the observers and turn into a cross -signed paypal state, "with money taken from nowhere and disappearing into nowhere, so long as the signatures were."
For a constant, let's take an average world internet connection - 1 megabyte per second , and declare that the user opening the wallet once a week should at best wait no longer than 10 minutes to synchronize with the rest of the network. This comes out just the current bandwidth usage in Bitcoin Core. You can read more about this parameter, which I dubbed weekly sync friction here.
Many new “pseudo” blockchains like to declare tps (transaction per second) in the region of 10 and even 100k (for example, bitshares). However, starting to read “fine print” about them you can see that they assume a gigabit connection and devilishly powerful servers. Obviously, on any laptop is not run. This is a couple of dozen ful nods spinning in a centralized cloud, or even generally in one data center, in which nothing is left of the blockchain.
Do we need 100k tps? Everyone decides for himself, but I believe in sound money - tsiferki on the screen that I can send to anyone on earth, and he will accept them understanding their value as I, not steaming about the volume of the unit and paying meager commissions. This means that such a system should support absolutely any transfer of value for all of humanity. Roughly estimating that there are 5 billion entities (all solvent people + businesses) performing 1 transaction per day requires 58,000 tps. And if we estimate that these transactions are not 1 and 10 (the world of Internet commerce is growing by leaps and bounds) then all 580k. Such a volume of average tps is simply impossible to fit on-chain, neither now nor 10 years from now.
Satoshi himself naively believed in 2009 that the power of computers will grow so fast that we do not need off-chain scaling. It turned out that an ordinary concierge is already doing so well, so why try harder? Apple is not going to invest in the development of 10 terabyte iPhones with 1 Gigabit Internet so that you can run the blockchain inside. This is real, but for them there is no commercial interest.
So it is necessary to work with what is. Or rather, even with a hundred times less technical requirements - no user will want to keep a laptop around the clock just to keep pace with the network of some blockchain.
On the contrary, the full node should be a small utility in the corner of the system , quietly devouring 1% of Internet traffic, 1% of disk space and 1% of processor power. Otherwise, it will be removed - what actually happened now with Bitcoin and ethereum. It became almost impossible to run a full node on a laptop, and everyone switched to SPV wallets or even websites like myetherwallet.com (which can be hacked at any second, replace .js files and merge your private keys).
By and large, 3 options are offered. Sharding - when a blockchain is divided into shards, and your client becomes an analogue of SPV when working with someone else's shards, side chains / plasma where you create a separate blockchain that can be “fat” but has to send checkpoints to the main chain so that it can be caught and punished. Both options slightly increase tps, are good only for microtransactions and have a bad effect on decentralization - we will not talk about them. The third option is systems built on the basis of payment channels such as lightning and raiden.
A channel in essence is an ad in the blockchain that two participants further decide the balance of a certain account between them two, multisig for two.
In the play-channel the double play is not possible, since it is two-sided. And if I get a commentary for the amount of X (signed line from another participant) I am 100% sure that I will receive X because he could no longer promise them to anyone. Blockchain here is the role of an arbiter, to whom they turn when it is necessary to close this channel and each to take their part of the money.
There are very few people who make sense to open channels among themselves, since everyone pays to different people. Therefore, it is logical to assume that the system can benefit only if there are hubs. Alice opens the channel to the hub, the hub opens the channel to Bob, Alice pays the hub, the hub pays Bob, everyone is happy.
This strategy is considered the main one in scaling Bitcoin - you can read more on the LN website.
If you think about this architecture, you can see a serious blunder in the model of participants' motivations. Yes, Alice costs nothing to open the channel for 100 bucks to the hub, but in order for the hub to open the channel to Bob he needs to invest his own money by sending the transaction to the blockchain.
Bob may be an ephemeral bot, and this may be the only translation in his direction. Channels make sense only when they are used repeatedly - hundreds and thousands of times, but if it is rarely used, then it is unprofitable for the hub.
Also, the channel has a volume - Alice will not be able to send more than 100 bucks what is in the channel (otherwise the hub theoretically will simply not be able to pick them up from the blockchain contract, because there are only 100 in it). The same output problem - if Bob’s hub has a channel for only 50 bucks, then Alice will not be able to pay more than 50 bucks in the direction of Bob through the hub - the capacity is calculated through the minimum channel on the chain, and the hub simply cannot promise and send a cryptographic Bob's comment for more than 50 bucks.
I dubbed this problem incentive / cost / capacity - the hub has no motivation to open channels without careful KYC (know your customer + anti money laundry), operating the hub is very expensive and you need to invest your own money, and the output channels of the hub always have a limited capacity and therefore many Payments simply fail (you are in a cafe and from you to the owner of the cafe there is not enough $ 1 in the volume of channels - you are not able to pay despite your own channel to the hub of 100 bucks). I described this problem in detail in the same article.
So we smoothly approached what I have been working on for six months. FS as a concept is also a solution for scaling an ordinary blockchain, but I also developed a new blockchain from scratch, which this solution includes out of the box.
Demo https://fairlayer.com/#install
The system takes as a basis the lightning network and adds the ability to send money into debt. . Those. where the LN falls on the blades and says that the route / capacity is not found in some direction in the FS hub simply promises this amount to its user, and this cryptographic promise can also be sent to the blockchain and receive money from it (but provided that the hub does not hacked and has this money).
The self-signed payment order we call delta - the deviation of your ofchein balance from the current balance (aka collateral, insurance). In lightning, they use the name “transaction” (because what you give to the hub is essentially a valid bitcoin transaction - this is not so, this is a special formatted line), in raiden (an etheric alternative sharpened by an ERC-20 token), this is called balance proof.
In this way, we achieve endless scaling off ofchein, keeping the blockchain itself small, which is not difficult to be full on a laptop or smartphone.
Now every member of the network does not inform everyone else about the transfer for a coffee or an apartment - instead, almost all payments (except for absolutely huge millions of dollars) must pass through hubs.
Each participant can choose 1 or more hubs with which he will hold the channel. It is still unclear how these hubs will be created, but the most logical is that geographically. And so Moscow hub can serve all residents of Moscow.
What does the payment look like?
Thus, we not only solve the block volume problem, but also make the payment procedure extremely cheap and instantaneous - which is ideal for offline commerce and quite a nice addition for online (no one wants to wait 30 minutes for 3 confirmations).
The hub, in turn, should make intelligent machines lerning on the deltas statistics of all users. When the delta is -10, this means the hub owns 10 units from this user's channel. When the delta +10 means the hub promised this user to add 10 units to the channel.
There is a risk that the hub will promise more money than it has in the negative deltas - and therefore the hub is obliged to rebalance its channels as soon as they outweigh certain amounts, for example <-100 and> +100.
The blockchain itself turns into a lightweight snapshot of insurance (insurance). Part of the balance will be insured - just like in Bitcoin, this balance is guaranteed and will survive even after the full break-in of the hub, and a small part of the uninsured balance is the promised balance with some users.
.
After considerable hesitation, those users who have spent a lot (sent a negative delta to the hub) get money and are given to those who have already earned a lot of money, and are running on all users' computers. These transactions will be rare and lightweight, while millions of transactions go through ofchein without leaving a trace of themselves inside the blockchain.
Everyone will see inside their wallet who has how much money is stored in the hub, or rather “with the hub” (this is the main difference between the hub and the bank - the money does not belong to the hub, it is only their temporary holder) - and receive only these rebalances from the network insurance with a hub. But no one will know to whom, when and how much you sent only the final result at the end of the week that your balance decreased by $ 10,000.
The most cool thing is that most users will barely touch the blockchain and will avoid onchain commissions (which will be in the region of 10-100 bucks just like in Bitcoin) if they structure the payment flows around themselves correctly (streaming money). Every dollar received will be directed to renting or paying a loan - and the delta size always tends to 0, which means almost the entire user balance is always insured and has the same properties as Bitcoin.
All hubs exist independently of each other (like ISP hubs on the Internet), can have channels with each other with certain risk limits (just like a correspondent bank account), and share a common settlement layer (which is a replacement for the central bank). And this whole system is able to withstand millions of transactions per second without detrimentalizing decentralization to the first layer (on which only insurance is kept that is very rarely rebalanced)
PS: I wrote and was horrified myself how impregnated everything was with strange terms and difficult to describe. Excuse me in advance, the concept is two-level and very complex, and many cool chips like embedded snapshots and decentralized installation are not included in the text - I will answer all questions with pleasure.
With the system, as I said, you can play on fairlayer.com and the prototype code is on GitHub .
This happens because the block size is limited to a constant value, and those who want to fit their transaction into a block are noticeably larger than before. What causes competition for the commission and its natural growth.
It is logical that by increasing the block we will be able to accommodate more people, which means to postpone the problem ? On the one hand - yes - so did Bitcoin Cash, the whole essence of which is to increase the block size to 8 MB.
')
On the other hand, no. About this, and about Fairlayer developed blockchain which elegantly solves this problem - under the cut.
1. With the increase in bloksayza it becomes more difficult to contain Fulnod
I remind you that the only correct way to use cryptocurrency is to be full-value - otherwise you rely on the cartel of miners to follow the rules of consensus. Miners / validators need to maximize profits, and as soon as they feel the power, they will start banning unwanted ones, create unspent transaction outputs from the air, and so on.
Each node verifying each state motion is a guarantee of a decentralized and honest network. Recently it has become fashionable to say that simple payment verification is normal and that we somehow believe the miners that they do not double the special. We will not go into this - anyone can google why the maximum number of fulls is extremely important, and why the laptop should always be fully full, otherwise the network is centralized around state keepers, who at some point can simply stop distributing new blocks to the observers and turn into a cross -signed paypal state, "with money taken from nowhere and disappearing into nowhere, so long as the signatures were."
For a constant, let's take an average world internet connection - 1 megabyte per second , and declare that the user opening the wallet once a week should at best wait no longer than 10 minutes to synchronize with the rest of the network. This comes out just the current bandwidth usage in Bitcoin Core. You can read more about this parameter, which I dubbed weekly sync friction here.
The second problem with bloksayza is that even he has practical limits.
Many new “pseudo” blockchains like to declare tps (transaction per second) in the region of 10 and even 100k (for example, bitshares). However, starting to read “fine print” about them you can see that they assume a gigabit connection and devilishly powerful servers. Obviously, on any laptop is not run. This is a couple of dozen ful nods spinning in a centralized cloud, or even generally in one data center, in which nothing is left of the blockchain.
Do we need 100k tps? Everyone decides for himself, but I believe in sound money - tsiferki on the screen that I can send to anyone on earth, and he will accept them understanding their value as I, not steaming about the volume of the unit and paying meager commissions. This means that such a system should support absolutely any transfer of value for all of humanity. Roughly estimating that there are 5 billion entities (all solvent people + businesses) performing 1 transaction per day requires 58,000 tps. And if we estimate that these transactions are not 1 and 10 (the world of Internet commerce is growing by leaps and bounds) then all 580k. Such a volume of average tps is simply impossible to fit on-chain, neither now nor 10 years from now.
Satoshi himself naively believed in 2009 that the power of computers will grow so fast that we do not need off-chain scaling. It turned out that an ordinary concierge is already doing so well, so why try harder? Apple is not going to invest in the development of 10 terabyte iPhones with 1 Gigabit Internet so that you can run the blockchain inside. This is real, but for them there is no commercial interest.
So it is necessary to work with what is. Or rather, even with a hundred times less technical requirements - no user will want to keep a laptop around the clock just to keep pace with the network of some blockchain.
On the contrary, the full node should be a small utility in the corner of the system , quietly devouring 1% of Internet traffic, 1% of disk space and 1% of processor power. Otherwise, it will be removed - what actually happened now with Bitcoin and ethereum. It became almost impossible to run a full node on a laptop, and everyone switched to SPV wallets or even websites like myetherwallet.com (which can be hacked at any second, replace .js files and merge your private keys).
And what are the alternatives?
By and large, 3 options are offered. Sharding - when a blockchain is divided into shards, and your client becomes an analogue of SPV when working with someone else's shards, side chains / plasma where you create a separate blockchain that can be “fat” but has to send checkpoints to the main chain so that it can be caught and punished. Both options slightly increase tps, are good only for microtransactions and have a bad effect on decentralization - we will not talk about them. The third option is systems built on the basis of payment channels such as lightning and raiden.
A channel in essence is an ad in the blockchain that two participants further decide the balance of a certain account between them two, multisig for two.
In the play-channel the double play is not possible, since it is two-sided. And if I get a commentary for the amount of X (signed line from another participant) I am 100% sure that I will receive X because he could no longer promise them to anyone. Blockchain here is the role of an arbiter, to whom they turn when it is necessary to close this channel and each to take their part of the money.
There are very few people who make sense to open channels among themselves, since everyone pays to different people. Therefore, it is logical to assume that the system can benefit only if there are hubs. Alice opens the channel to the hub, the hub opens the channel to Bob, Alice pays the hub, the hub pays Bob, everyone is happy.
This strategy is considered the main one in scaling Bitcoin - you can read more on the LN website.
Lightning and liquidity
If you think about this architecture, you can see a serious blunder in the model of participants' motivations. Yes, Alice costs nothing to open the channel for 100 bucks to the hub, but in order for the hub to open the channel to Bob he needs to invest his own money by sending the transaction to the blockchain.
Bob may be an ephemeral bot, and this may be the only translation in his direction. Channels make sense only when they are used repeatedly - hundreds and thousands of times, but if it is rarely used, then it is unprofitable for the hub.
Also, the channel has a volume - Alice will not be able to send more than 100 bucks what is in the channel (otherwise the hub theoretically will simply not be able to pick them up from the blockchain contract, because there are only 100 in it). The same output problem - if Bob’s hub has a channel for only 50 bucks, then Alice will not be able to pay more than 50 bucks in the direction of Bob through the hub - the capacity is calculated through the minimum channel on the chain, and the hub simply cannot promise and send a cryptographic Bob's comment for more than 50 bucks.
I dubbed this problem incentive / cost / capacity - the hub has no motivation to open channels without careful KYC (know your customer + anti money laundry), operating the hub is very expensive and you need to invest your own money, and the output channels of the hub always have a limited capacity and therefore many Payments simply fail (you are in a cafe and from you to the owner of the cafe there is not enough $ 1 in the volume of channels - you are not able to pay despite your own channel to the hub of 100 bucks). I described this problem in detail in the same article.
Fairlayer
So we smoothly approached what I have been working on for six months. FS as a concept is also a solution for scaling an ordinary blockchain, but I also developed a new blockchain from scratch, which this solution includes out of the box.
Demo https://fairlayer.com/#install
The system takes as a basis the lightning network and adds the ability to send money into debt. . Those. where the LN falls on the blades and says that the route / capacity is not found in some direction in the FS hub simply promises this amount to its user, and this cryptographic promise can also be sent to the blockchain and receive money from it (but provided that the hub does not hacked and has this money).
The self-signed payment order we call delta - the deviation of your ofchein balance from the current balance (aka collateral, insurance). In lightning, they use the name “transaction” (because what you give to the hub is essentially a valid bitcoin transaction - this is not so, this is a special formatted line), in raiden (an etheric alternative sharpened by an ERC-20 token), this is called balance proof.
In this way, we achieve endless scaling off ofchein, keeping the blockchain itself small, which is not difficult to be full on a laptop or smartphone.
Now every member of the network does not inform everyone else about the transfer for a coffee or an apartment - instead, almost all payments (except for absolutely huge millions of dollars) must pass through hubs.
Each participant can choose 1 or more hubs with which he will hold the channel. It is still unclear how these hubs will be created, but the most logical is that geographically. And so Moscow hub can serve all residents of Moscow.
What does the payment look like?
- Alice comes to the cafe and asks for the bill.
- Alice touches the phone / scans QR, her wallet takes the last delta value stored with the local hub and reduces this delta by the amount of the purchase.
- This signed delta is sent straight to the hub server with the note “send this cafe to U for this invoice X).
- The hub verifies the delta change and finds out how much Alice is paying. It is convinced that the amount of payment is less than or equal to the size of the channel (Alice herself cannot pay the debt yet.
But this is for now - credit cards in this system are also provided) - The hub searches the system for an open web socket in the direction of cafe U, pulls out the latest delta from this database from its database and increases it by the same amount minus the fee of commission (0.1%
at the moment - 30 times smaller than a visa and payal) - The payment terminal or smartphone of the cafe owner receives a new delta from the hub and a note for which invoice the payment arrived. If the amount of the invoice and how much the delta was increased are equal, the invoice is marked as paid. Alice can go.
Thus, we not only solve the block volume problem, but also make the payment procedure extremely cheap and instantaneous - which is ideal for offline commerce and quite a nice addition for online (no one wants to wait 30 minutes for 3 confirmations).
The hub, in turn, should make intelligent machines lerning on the deltas statistics of all users. When the delta is -10, this means the hub owns 10 units from this user's channel. When the delta +10 means the hub promised this user to add 10 units to the channel.
There is a risk that the hub will promise more money than it has in the negative deltas - and therefore the hub is obliged to rebalance its channels as soon as they outweigh certain amounts, for example <-100 and> +100.
The blockchain itself turns into a lightweight snapshot of insurance (insurance). Part of the balance will be insured - just like in Bitcoin, this balance is guaranteed and will survive even after the full break-in of the hub, and a small part of the uninsured balance is the promised balance with some users.
.After considerable hesitation, those users who have spent a lot (sent a negative delta to the hub) get money and are given to those who have already earned a lot of money, and are running on all users' computers. These transactions will be rare and lightweight, while millions of transactions go through ofchein without leaving a trace of themselves inside the blockchain.
Everyone will see inside their wallet who has how much money is stored in the hub, or rather “with the hub” (this is the main difference between the hub and the bank - the money does not belong to the hub, it is only their temporary holder) - and receive only these rebalances from the network insurance with a hub. But no one will know to whom, when and how much you sent only the final result at the end of the week that your balance decreased by $ 10,000.
The most cool thing is that most users will barely touch the blockchain and will avoid onchain commissions (which will be in the region of 10-100 bucks just like in Bitcoin) if they structure the payment flows around themselves correctly (streaming money). Every dollar received will be directed to renting or paying a loan - and the delta size always tends to 0, which means almost the entire user balance is always insured and has the same properties as Bitcoin.
All hubs exist independently of each other (like ISP hubs on the Internet), can have channels with each other with certain risk limits (just like a correspondent bank account), and share a common settlement layer (which is a replacement for the central bank). And this whole system is able to withstand millions of transactions per second without detrimentalizing decentralization to the first layer (on which only insurance is kept that is very rarely rebalanced)
PS: I wrote and was horrified myself how impregnated everything was with strange terms and difficult to describe. Excuse me in advance, the concept is two-level and very complex, and many cool chips like embedded snapshots and decentralized installation are not included in the text - I will answer all questions with pleasure.
With the system, as I said, you can play on fairlayer.com and the prototype code is on GitHub .
Source: https://habr.com/ru/post/347090/
All Articles