Spiderchains: Proof of Stake (Layer 2). ScrgruppEn

This is an extension of my previous series of articles discussing the various sidechain proposals out there. These articles can be found here: Space Chains, Space Chains Use Cases, Soft Chains, Command Chains, Standard Chains, and Side Chain Swaps.

Botanix Laboratories Recently I proposed a completely new side design called Spider chains, for the purposes of transferring an Ethereum virtual machine to a platform connected to the Bitcoin network. The architecture is a very significant departure from most previous proposals for concrete designs. First, it does not directly involve miners in consensus or use embedded mining in any of its various forms. Second, it uses multi-signature bonds and surety bonds to create a second layer of proof-of-stake system on top of Bitcoin. Third, it does not require any changes to Bitcoin to be deployed.

The first thing to clarify is that, technically, a spider chain is not actually a side chain. Any sidechain posted using spider chains will be placed “on top” of the spider chain that is above the base layer in the main chain. Sidechain blocks will be produced independently by project maintainers (referred to as coordinators in the paper) in the consensus system. Spiderchain, rather than being an actual sidechain, is a kind of additional layer that facilitates keeping user funds and stakeholder bonds on the mainnet. Think of it like the middle of the sandwich between the side chain and the main chain.

Proof of quota variable

To get a better idea of ​​how the system works, let’s walk through how the Botanix EVM chain interacts with the Spiderchain layer. One of the first uses the system has for the Bitcoin blockchain aside from the actual custody of the funds backing the Sidechain tokens is to choose a block creator. Proof-of-stake chains require a selection process in which the administrator actually puts together blocks from transactions in the memory pool. In Proof of Work, all miners do this independently and whoever is lucky enough to find a valid block header hash gets their block accepted into the blockchain. Since the primary goal of proof-of-stake is to eliminate energy-intensive randomization of who chooses the next block, these systems need another solution. They use a verifiable random function (VRF), a function that allows all participants to verify that the outcome is truly random and not biased or deterministic. Spiderchains use Bitcoin hashes in order to obtain verifiable randomness.

Just like other proof-of-stake systems, Botanix divides the blockchain into separate sections called “epochs” which are periodically finalized and a new block creator is chosen. At the beginning of the era, the main blockchain is taken and applied as a source of randomness to all contributors to choose a new block creator. After six blocks, to account for the possibility of reorganization, the network switches to the new block creator for that epoch. Now this describes the way the proof-of-stake system handles building a block on the sidechain and reaching consensus on who will take over, it’s time to get into how all of this interacts with the spider chain (and what exactly a spider chain is).

Spider chain

In addition to being used periodically to select a block creator, the sidechain also uses VRF to select a random subset of contributors to generate a multi-signature address for deposits into the sidechain for every single Bitcoin block. That’s right, a random set of members for multilinking. Unlike the federation sidechain, which stores funds in addresses made up of the entire pool of federation memberships, spider chains partition each deposit (or change from transactions linked outside the sidechain) to a unique address depending on which block the main chain confirms in its composition from a random subset. From a group of stakeholders. For example, if there are 50 people sharing any given block of Rise, 10 of them will be randomly selected to be the key holders for any deposits that occur in the next block. This may sound a bit crazy, but there are some sound logical reasons for this.

It separates money risks from malicious parties. Most people think of theft, but even loss of vitality can be disastrous for systems like this. Think of a federated sidechain, you don’t need a malicious majority to make a big problem, just a malicious minority. If a federation requires a threshold of 2/3 to move coins, just 1/3 + 1 member is enough to keep those coins frozen (which is why Liquid has a time-delayed emergency recovery path with Blockstream keys saved to prevent the coin from being permanently lost in This situation). You don’t even need any malicious actors in the strict sense, just losing the key can create this problem. By dividing deposits into isolated subset keys with random members, you alleviate (not solve) problems like this. If the keys are lost, or a malicious actor manages to obtain a sufficient percentage of stakes in the system to stall or steal, they will statistically not be able to access all of the funds in the spider chain. Each block has completely independent possibilities of creating a deposit address controlled by a malicious majority (or implemented by a malicious minority), and if these conditions are met, then funds deposited or migrated solely through change from withdrawals in that particular block will be at risk rather than the entire block. Sidechain funds.

There is also another interesting security property derived from how withdrawals are handled. Any side linking mechanism that does not aggregate all deposits into one rolling UTXO raises the question of which UTXO should be used to execute withdrawals. The design of the spider chain has settled on the Last In First Out (LIFO) principle, meaning that any withdrawals from the sidechain will be processed using the most recently deposited UTXOs. Think of this in the context of malicious entities joining a stakeholder group in order to steal money from the spider chain. All funds deposited before those malicious entities become majority are completely safe and protected from them until any withdrawal requirements are triggered that entail spending those funds and rolling over the change to new addresses. Now, even after they become the majority of stakeholders, they will only be able to access the funds when they randomly end up as the majority of the main members of the deposit address generation protocol. So, even after they get in and take over, they won’t have full access to all the deposited funds after that fact due to the deposit address being created using the VRF.

This series of multiple randomly generated marks is the spider chain, which is the clamping mechanism used to lock and unlock coins on and off the sidechain.

Mortgage bonds

The final part of any Proof of Stake system is bonds, which are very simple. If stakeholders are not asked to provide anything in exchange for guarantees in exchange for participating in the consensus mechanism, then there is nothing to be taken from them as a penalty for malicious behavior. This is achieved by using spider chain. In the same way that deposit addresses are generated for users, a new deposit address is created for each block for people who want to participate in the sidechain to deposit a bond in a multisig consisting of a random group of existing contributors. Once this bond is confirmed, the new member is recognized as a partner and is included in the overall pool from which new block creators and deposit address members are selected.

At this point, if a stakeholder fails to respond and stay online or engages in malicious behavior, they can be punished through severance and, if necessary, eventually removed from the stakeholder group by severing the entire stakeholder. The nice thing about the way this is done is the cut-off policy, that is, the amount of penalties for certain actions or misconduct, is neither programmatic nor social, but both. The cut occurs programmatically on the underlying layer of the main chain, but is socially initiated by key holders in the staking document. This means that there is the potential for things to get a bit messy, but there is flexibility in adjusting things to find a balance that keeps things working in a way that is beneficial to stakeholders and users.

Gluing it all together

Take the idea of ​​proof of ownership as a basic consensus mechanism, and ditch the idea for now. This is not the case, and the issues that need to be solved to enable Proof of Stake as a second layer system rather than a standalone base layer are not the same. Proof of Ownership is essentially a union, but anyone can join and cannot be prevented from doing so, with a mechanism to punish members for malicious behavior. As a basic layer it creates all sorts of existential issues, such as the objectivity of punishment reduction. Proof of Stake as a second layer does not have this problem when the shard links are on the main chain, and governed by Proof of Work.

The problem with proof of ownership as a second layer is how you can ensure that new members cannot be turned away from the “union”. If all funds are in the custody of existing members, the majority (or a malicious 1/3+1 minority) can prevent any funds from being transferred to multisig with new members included. They may be prevented from joining. The way deposits and mortgages make use of the spider chain, which is randomly generated by multisigs made up of subsets of the ‘union’, it elegantly solves the problem of existing members being able to exclude new ones. Everything that governs address members and new entrants can be verified and enforced through Layer 2 consensus with information viewable on the mainnet and governed by proof of work. Once someone posts a bond, they become part of the group selected to hold deposits and other mortgage securities. Everything is there and can be verified.

It also creates some interesting security properties and dynamics based on how it works. In a consolidated sidechain, spot funds were rotated into multiple tokens consisting of a sufficient number of malicious entities, resulting in the hacking of the entire sidechain funds. Using the spider chain, the introduction of a new malicious majority can be mitigated almost completely if they are quickly identified. Simply halting new deposits until they are cut off can reduce enough malicious participants that they can keep the amount of money at risk limited to the statistical fraction of new deposits that end up at addresses they have controlled since they became the majority. They will not be able to lower any old bonds before they enter, but pre-existing members will be able to statistically lower a portion of their bonds.

As long as the amount of individual multi-signatures is properly balanced with the total number of pledgers, and the value of all deposits compared to the pledged bonds, this can be a very practical system.

Overall, it’s a very interesting proposal that proposes interesting solutions to the problems of “upgrading” federations to a proof-of-stake system: the ability for anyone to join, protection mechanisms from malicious members, and an incentive to participate because stakeholders can split transaction fees. Kicker? Why should you care? It doesn’t require any fork at all to enable it, so it will happen.

The most trusted voice in bitcoin, Bitcoin Magazine provides news, analysis, information, commentary, and price data about Bitcoin blockchain tech