OPRR Flash Depth Activities

Search Extension

Acala CTO analyzes the underlying technology of poka: shared security and parallel chain card slots

BeWater

21-11-25 18:45

Read this article in 43 Minutes

AI summary

View the summary

Analysis of Boca Underlying Technology: Shared Security and Parallel Chain Card Slots

Chen Xiliang (Co-founder and CTO of Acala Network)

Source: BeWater Community

Editor: Yu Cheng & NBSP;

Introduction to Boca architecture

Poca is a heterogeneous blockchain. As the first generation of blockchain, bitcoin's main function is to transfer money. Ethereum has a smart contract function as the second generation of blockchain, which allows users to upload smart contracts and then publish their own applications. But Ethereum has reached a plateau: everyone, including ethereum officials themselves, has decided that Ethereum is not ready for the future, so Gavin Wood left Ethereum to create Boca to build what he believes is the best web 3.0 technology for the long term.

At present, one of the biggest bottlenecks of blockchain is performance limitation. There are several ways to solve the performance bottleneck: horizontal development and vertical development.

Vertical development is stratification, horizontal development is fragmentation. Boca uses the technique of sharding. Ethereum 2.0 is similar, but Ethereum 2.0 uses isomorphic shards and Boca uses heterogeneous shards. You can implement Ethereum 2.0 with Poka, as long as each shard is a smart contract slice. Therefore, isomorphic sharding is obviously better than isomorphic sharding in terms of technical architecture, because as long as isomorphic sharding technology can be realized, isomorphic sharding technology can be very simple.

This diagram is a very simple architecture of Boca, with several roles: The Relay Chain in the middle is boca Relay Chain, and each Relay Chain will connect multiple parachains. Each Parachain is a parallel Chain, and each parallel Chain is its own Chain, which becomes its own layer 1. Therefore, boca connects all parallel chains. Some people say that Boca is a Layer 0 protocol.

Each parallel chain is secured by Validators, who maintain the security of the entire Boca network. Then the Validators also validate the parallel security, and there are Collators for each parallel chain, which I'll cover in more detail later. That boca ecosystem as a cross-chain core, naturally can not be a very closed ecosystem, we hope to be able to connect to boca ecosystem, as well as Ethereum, other emerging ecosystems, to create an interconnected future of blockchain 3.0. So the bridge is also a very important part of this ecology.

The bridge is actually a normal parallel chain, but its purpose is to cross other chains. So the bridge allows the Boca ecosystem to connect to other ecosystems, including Bitcoin, Ethereum, etc. Some of these Bridges are already being implemented and some are being implemented, so you can create a completely open ecosystem that can interconnect the entire blockchain network.

https://wiki.polkadot.network/docs/getting-started

https://research.web3.foundation/en/latest/index.html

https://w3f.github.io/parachain-implementers-guide/

https://docs.substrate.io

Boca architecture shares security design concepts

1. Decentralization-npos validates the human election algorithm

The first is decentralization. Boca hopes to support at least 1,000 verifier nodes, a very decentralized network.

If there are so many people in the world competing for 21 nodes, the cost of becoming a node will be very high, but if you compete for the first 1,000 nodes, the cost will be much lower. Of course, how to choose the first 1000 nodes in a decentralized way is also relatively complicated.

In a simple way, each coin holder can act as a nominee, and the nominee can elect a verifier. However, the problem is that the nominee can only elect one verifier, and the nominee can only get benefits after his or her elected verifier is elected. The result is only a network of 21 verifiers. The difference in votes between the 21st person and the 22nd person was huge. So as a result, it's very easy for the incumbents to stay in the circle, and it's very difficult for outsiders to tip the balance. So this is actually not the ideal state for decentralization.

Poka implements an NPoS algorithm: each verifier can elect up to 24 verifiers, and as long as any one of them is elected, you get 10 staking. This gives people an incentive to choose someone they think is a better validator, rather than someone they are sure to choose. This does not create very high barriers, making it easier for new verifiers to join.

So the voting algorithm gets a little more complicated. Because one person has 24 votes, which are allocated dynamically, the global algorithm is complicated. The Sequential Phragmen algorithm is used to verify that human election is very decentralized, so it is one of boca's decentralization.

https://wiki.polkadot.network/docs/learn-phragmen

https://research.web3.foundation/en/latest/polkadot/NPoS/index.html

2, safe -BABE out of the block election algorithm

As a blockchain network, security is naturally very important. Boca has all sorts of ways to keep it safe. I'll focus on the BABE block-generating algorithm first. Because Boca can support thousands of verifiers, but it is impossible for each block to have thousands of verifiers produce a block at the same time, so how to choose the next block maker is also a problem.

This practice is generally there are two ways, the easiest way is to use a line in order to take turns to people, one a piece is finished, this is feasible, but he will have some problems, such as who is the next piece of man is predictable, will make some attack is easier to realize, this is more dangerous.

The second way is to use VRF (Verifiable Random Function) The way. This means that there is a degree of randomness in how blocks are elected, and there is no way to predict who will be next. The advantage is that the verifier is much less likely to collaborate in evil, because he doesn't know when he's going to be elected, and he doesn't know who the next few verifiers will be after he's elected, plus there are thousands of verifiers, and the cost of collaborating with a few people increases dramatically.

VRF has a slot, and every 6 seconds is a block block interval. At this time, each validator knows that he or she has a check, which only he or she can see. The check is drawn every 6 seconds, and if he or she wins the check, he or she has the right to draw the block. At the same time when the block is drawn, a proof can be issued that he has indeed drawn the pick.

Of course, there's a small problem with a random draw. There's no guarantee that only one person will be chosen, and there's no guarantee that someone will be chosen. It is possible to have multiple validators or no validators in a slot. BABE also does some processing. Multiple validators can easily lead to a fork, but in the end only one fork will be legal.

If none is selected, the slot will have a primary as the primary producer and a secondary as the secondary producer. Primary is a method that uses VRF to select, so if no one is selected or the selected person is not online, or if for some reason he doesn't come out and say he selected, he doesn't do the block. Then there will be a substitute, and that substitute can come out and do a block. Which makes in the validation of the piece to achieve a better randomness, and at the same time make some outsiders attack more difficult: for example, you can quickly and the forecast to the next block, you can on the network, server, you can act as a DOS attack, send a bunch of flow, to break off the server, the network paralysis.

But if you don't know who's next, and you have to attack thousands of verifiers at the same time, the cost of the attack is a thousand times higher, so it makes the network more secure. BABE is not a perfect algorithm, boca is doing this SASSFRAS algorithm so that there will be only one, and definitely only one, blocker between each slot. There won't be multiple people drawing a lot at the same time, or there won't be any people drawing a lot at the same time. The algorithm is now in an audit phase.

https://wiki.polkadot.network/docs/learn-consensus#block-production-babe

https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html

3. Efficient -GRANDPA Block final confirmation algorithm

And then the next word as a new generation of blockchain network, then we have to ensure that the network is an efficient. So this one, also, I'm going to -- I'm just going to say one of the more important things is the GRANDPA algorithm. A BABE is someone who chooses who is the blocker and who has the right to blocker. GRANDPA is doing such a process for the final confirmation. Because Babe's words can still lead to the fork.

The GRANDPA does this confirmation if, in the case of a fork, who is the real one is pinched to a block. The GRANDPA algorithm is an extension of the traditional PBFT algorithm. It is almost identical in principle, requiring more than 2/3 of the honest nodes to prevent Byzantine attacks.

GRANDPA, however, has one of the biggest advantages over traditional Finalize algorithms, that is, it can finalize a large number of blocks quickly at one time. As a traditional algorithm such as PBFT, it can only finalize one block at a time, which directly limits its efficiency. But GRANDPA can, in theory, hammer out hundreds or thousands of blocks at once.

So it makes the network in the case of network failure or some nodes down, if it is the traditional Tendermint algorithm, it will directly cause the network stagnation. GRANDPA: [GRANDPA] The network stops up the GRANDPA. [GRANDPA] The network stops up the GRANDPA. But its Finalize will stop, but once the network comes back to normal, once enough nodes come online, it can directly catch up with the finalized block ina few seconds.

https://wiki.polkadot.network/docs/learn-consensus#finality-gadget-grandpa

https://research.web3.foundation/en/latest/polkadot/finality.html

Boca architecture shares security technical details

1. Off-chain worker and election algorithm

There are thousands of nominees, thousands of validators on Boca. So if you're going to pick the best of these people and you're going to have 200 or 300 validators, no matter how optimized the algorithm is, it's going to be a lot of computation. You should know that the computation on the chain is very expensive, because it requires every node to perform the computation, and it is time-limited. So it's not a very good idea to do this on a chain.

Boca's network is a six-second block. Six seconds is generally divided into three parts, of which two seconds is the time of block generation, two seconds is the time of network transmission, and two seconds is the time of introducing the last block. So it's 6 seconds, but there's only 2 seconds for the block. So it's a direct constraint that this election algorithm has to execute in less than two seconds. This works when the number of people on the network is small, but becomes a very big limitation when the number of people on the network is large. So Boca uses the technology of off-chain-worker to solve this problem. This is also a relatively new technology, as far as I know it is not available on other networks.

To put it simply, the off-chain-worker can make a piece of code execute in the chain on the network. Phragmen is an algorithm that computes nodes down the chain to find the best nominee. And then you do the calculations and then you upload the best solution to the chain. Because verifying the scheme is a relatively quick process. This then allows an election to take place in a performance appropriate way, with a lot of computation going down the chain, where only the scores are good enough to vote for. This breaks the two-second execution time limit on the chain.

In addition to this, off-chain-worker can also do many other things. For example, the heartbeat used for sending authentication is also executed using the off-chain-worker. And the off-chain-worker has a lot of powerful apis, and it can even send HTTP requests. For example, in the simplest case, you can directly inquire the price with coinMarket Cap and other price sites, and then send the price information to the chain. You can do many things that are impossible with the traditional blockchain architecture. So this is also a unique advantage compared to other blockchain development frameworks.

https://docs.substrate.io/v3/concepts/off-chain-features/

https://wiki.polkadot.network/docs/learn-phragmen#off-chain-phragmen

2. Hybrid consensus algorithm

Boca's consensus algorithm is actually a hybrid algorithm. He makes a distinction between the output block and Finalize, and makes a split. Since BABE's statement is straightforward, as long as the node you randomly pick is online, or his alternate node is online, then he can play a block. As long as one node is online, even if all other nodes die, it will not affect the normal block generation of the network. So this has greatly improved the usability of the network.

Of course, for this security, we still need Finalize. Therefore, finalize still needs to have more than 2/3 honest nodes online. However, the two are separated, so if there is a problem in the network, BABE can generate a block by himself, and then finalize the block again ina few seconds after the network is restored. Therefore, this hybrid company algorithm greatly improves the availability and security of the network.

3. Verifier - collector architecture

And then the next one says this is more of a parallel chain extension, using the architecture of the collector validator. I just mentioned briefly that Boca is a relay chain, and then the intermediate chain has its own validator and then each of these validators and then these validators are responsible for verifying some of the security of the parallel chain, And then each of these parallel chains has its own collator and the collator is the collector, and he's responsible for the block generation of the parallel chain, but he's not responsible for the security, and all the security is performed by this Boca verifier.

So the result is that you don't have to trust Collator. These collators are inherently incapable of any evil. This makes it possible for a parallel chain to have only a few collators, as opposed to boca, who are incapable of doing evil anyway. This greatly improves the safety performance of parallel chain and greatly reduces the cost of running a parallel chain. Because you only need to have a few collators.

https://wiki.polkadot.network/docs/learn-collator

4. Technology expansion based on shared security

(1) Sharing security

So the biggest advantage of shared security is that all parallel chains can share the security of the network to the Boca main chain. This is a very important point. As a POS network, it is very difficult for you to have a good security performance. You must have a sufficient market value of the network's tokens, and you must have a sufficiently dispersed node. So there is a very high threshold in terms of both operations and capital. Boca's use of shared security technology allows the parallel chain to directly use the boca's security.

So this is a very necessary approach, otherwise the result will be different every network will inevitably have a competition on security. The simplest example is the forking of various Bitcoins, a small network between each miner that has a very low hash rate and is then vulnerable to a double-flower attack. At the same time, the small POS network, because the market value of the tokens is too low, so it is very easy to acquire enough tokens, and then carry out the 1/3 attack and so on.

But if the network of parallel chains is based on this boca security, then the cost of attacking any of the parallel chains is the same as the cost of attacking the Boca itself. That would be a very high cost. And then but this is just one of the points of sharing this shared security.

So shared security actually achieves another effect, which is also very important, and is actually in the service of this cross-chain technology. Because one of the things that's really hard to do is to cross technologies, if you have 100 blockchains that can communicate with each other, the coin can go around in those 100 chains. So you have a problem with this one, if one of these 100 chains ends up being attacked, and then it's being maliciously manipulated. So is it possible that this chain can issue infinitely more currency to the other chain, and then transfer that currency to the other chain in a cross-chain way, and then cause all of these other chains that are connected to this chain to be attacked.

So with shared security, you can ensure that there are no weaknesses in the network. After doing this cross-chain technology development, of course, we still have a lot of other technical details to consider. But one thing that doesn't need to be considered is whether the message on this chain is secure enough for the other chain. And because of the relay chain and parallel chain architecture, all cross-chain messages are authenticated by the validator of the relay chain and are guaranteed by the relay chain.

So another advantage that leads to is chain A sending A message to chain B. After chain B receives the message, it is actually guaranteed by the relay chain. The relay chain has actually verified that the message was sent by chain A. In this way, chain B can directly believe that the message is due to shared security. So the verification of multiple sources is completely out of the question. Therefore, this also makes the implementation of cross-chain technology much easier, so it is also one of the advantages of Boca cross-chain, which can temporarily achieve a very efficient cross-chain message transmission between chains and parallel chains.

(2) Governance issues

Then this only guarantees the validity of the transmission of messages between chains. But there is one problem that does not solve, the problem of governance. In theory, if all chains have the same underlying security, there is a governance attack.

You can say that there is a parallel chain and the price of its own Token is cheap enough, then the attacker can purchase a large number of the parallel chain Token, so that he can control the governance of the chain, and then even do some operations, such as maliciously issuing a large number of coins of other chains or tampering with some messages. The solution, then, is to attack the problem, boca also provides a solution.

Basically, for example, you have a trusted piece of hardware between your phone and your computer, a chip called TEE, which is included on your iPhone or your Mac, and even on most new cpus, there's a trusted execution area. And then everything that is implemented in this is considered to be credible. For example, if you use your fingerprint to unlock your iPhone, if you use FaceTime, all of the fingerprint information will be executed in this trusted area. The idea is that it cannot be manipulated by malicious attacks. This makes a lot of security stuff very easy to develop, because as soon as you implement it in TEE, you think it's safe.

A similar effect can be achieved. If parallel chain is used, SPREE does not have the ability to modify the code of the component, because the component is maintained by the relay chain, so it can put some very important and sensitive code, For example, the Token transfer, additional issuance and destruction logic are placed in this framework.

In this way, other parallel chains can trust that the corresponding Token transfer operation will be correctly executed. Other parallel chains even carry out malicious attacks, he also has no ability as a malicious add-on and so on. Because this logic in this part is not manipulated by other parallel chains, this also solves a lot of the trust problem, you don't have to trust each other, because they're not capable of evil. So this is one of the things that boca technology is very good at. At present, I don't see any other technologies that can solve this problem.

Of course the idea is very advanced. So far I haven't written a single line of code. So we may have to wait a while before we can actually use this feature on the SPREE. Of course, if you are interested, you are welcome to discuss some technical details of the SPREE. This is also going to be a very big focus of this development after the boca parallel chain goes live.

https://wiki.polkadot.network/docs/learn-security#shared-security

https://wiki.polkadot.network/docs/learn-crosschain

https://wiki.polkadot.network/docs/learn-spree

Parallel chains and parallel threads

1. Verify the human assignment mechanism

So let me say a few things about the slot. And of course I've already mentioned the price of Boca, we have the relay chain and the parallel chain. And then there's actually the idea of parallel threads. And of course this is actually very simple, parallel chains are basically like a multi-core computer, and then each chain is one core for each application, and then that core is unique to it, and then parallel threads are one thread and then they're equal to multiple threads sharing multiple cores. And then making it so that some of the applications that have low transaction volume, for example, it doesn't have to be online all the time, it can share a core with some of the same threads, and that allows the network to achieve a much more efficient allocation.

Of course, parallel threads are currently under development and are not available yet. But because its core function is the same as parallel chain. So hopefully we'll see parallel threads in the near future after this parallel chain goes live.

And then there's this assignment mechanism for the verifier. In this white paper in Boca, he would say that Boca would have 100 slots. So a lot of people have this question, why 100 slots? What if the 100 card slot is used up? What if it's not enough? And then the problem of not being enough is to be a second level relay so we have boca and the boca is connected to 100 parallel chains, and then the 100 average chains are themselves a relay chain, 100 chains are connected to 100 chains, so we have 10,000 chains, 10,000 chains 100 is not enough, Ten thousand should be enough. So this is the Boca solution. Where do we get the number 100? Boca was originally designed to support 1,000 verifiers, and then they would assign them, and then every 10 verifiers, and then they would be responsible for verifying one parallel chain. So we have 1,000 verifiers and 10 parallel chains, so we have the number 100.

Of course, because the maximum number of verifiers is not 1,000. How much of this limit is actually unknown, so Kusama will continue to increase the number of verifications and the number of verifications over the next year, exploring the limit of the number of verifications in the actual network. Then we'll know how many verifiers and parallel chains Boca can actually support. And then at the same time this 10 is the number that was set up.

Now each parallel chain is actually only assigned 5 verifiers. This is also Web3 and they did some more research later, and they thought that five verifiers could do it safely enough.

https://research.web3.foundation/en/latest/polkadot/networking/1-parachains.html

2. Anti-evil mechanisms

Of course, the question is, what if all five verifiers are working together? So boca's verification is not simply a matter of trusting the five validators. And of course the first thing is because of the probability of picking five out of a thousand, and then doing bad things together is because as a POS network, one of the basic assumptions is that at least 2/3 of the nodes are honest, and 1/3 of the nodes are bad, And then you have five randomly assigned to one of these parallel chains that you want to attack, and they think the probability is low enough that it's safe enough.

And even if that happens, this is just a first step verification. There's actually a second step of verification.

Boca I just said that the getout is separate from the final Finalize. So this is actually the same mechanism as the parallel chain. The five validators will validate the nodes of a parallel chain, package them in this block of the parallel chain, package the parallel chain block headers, and place them in the block of the Boca relay chain. The boca block will then perform a block output, and this will be considered as confirmed.

Confirmation is not enough, we usually have to finalize the process, this will involve the second mechanism of Boca. In the GRANDPA verification, they will perform another verification as a second step. And then to verify again that the block that these five people packaged the parallel chain is legitimate. So that makes these five odds of doing evil. Even if these five do evil things, they can package this illegal parallel chain block in Boca's block. This is equivalent to creating an illegal relay chain block, it may be confirmed, but it will never be finalize.

https://research.web3.foundation/en/latest/polkadot/networking/3-avail-valid.html

The slot auction

1. Boka Token economic design

In this traditional English auction, everyone bids and the highest bidder wins. There are also a lot of problems with doing things on blockchain. First of all, your auction must have a timeliness, you can't let the auction drag on forever, such as malicious attack, everyone conspire, each time an extra dollar, everyone does not want to auction more, then add a dollar each time, really do not know the monkey horse months. So Boca is using a candle auction, and this candle is an auction. Simply put the auction in two cycles, the first is an offering of a normal cycle, the second is a random quench cycle, then eventually after the auction ended, he will use to type VRF (variable refrigerant flowrate) provided that a random number, and then use the digital random select a block, by this block inside the highest price.

And then this is why this is in if you watch the Boca auction, you'll notice that it doesn't come out as soon as the auction ends, it usually takes two to four hours, it also waits for a secure random number to come out, and then you can do a block that confirms the auction result.

And then why did the candle development do that? The main problem they had to solve was that one was to ensure that the auction could be completed within a certain time frame of the game and could not be put off forever. The second is to avoid last-second bids, because in a normal auction with a time limit, the optimal strategy is to bid at the last second.

So this candle auction mechanism encourages people to turn in that chip as soon as possible, just before it goes out at random. Because you paid it and it doesn't matter if you bid at the last second before the last cycle of the new girl cycle starts. Well, everyone else will see your bid and add it later. Because mark-ups before the start of the actual period don't have that much impact. But if you choose to bid at the last second of the extinction cycle, there is a very high chance that the bid will be invalid. So this also makes the auction participation strategy, in a sense, much easier, because you just start all in. And so this is the candle auction.

https://research.web3.foundation/en/latest/polkadot/economics.html

https://wiki.polkadot.network/docs/learn-staking#inflation

2. Introduction to candle auction

And then here also by the way, boka's Token economy design. Because boka coin every blockchain project its coin should basically have a certain use. Boca sees his coin as a tool rather than a currency.

So there was a very radical idea in the early design of this Boca model, that this growth rate could be as much as 50 percent annualized. The result is that if you don't engage in staking, the substantial depreciation of your asset will. And then in a kind of forced way to get everyone involved in the network. Of course, this is something that everyone can say is too radical anyway. Therefore, it is not used in the end, so it is now using a relatively reasonable 10% increase rate. If you are interested in boca's economic head design, you can also see this link which has some very much information about some use.

I've been sharing for over an hour, so that's it for today, and then we're going to have a free q&A session, and then if you have any questions, you can take them now.

https://wiki.polkadot.network/docs/learn-auction