This is an extension to my previous article series discussing the different sidechain proposals that exist. Those articles can be found here: Spacechains, Spacechain Use Cases, Softchains, Drivechains, Federated Chains, and Trade Offs Of Sidechains.
Botanix Labs has proposed a completely new sidechain design recently, called spiderchains, for the purposes of porting the Ethereum Virtual Machine to a platform anchored to the Bitcoin network. The architecture is a pretty large deviation from most prior proposals for concrete designs. Firstly, it does not involve miners directly in consensus or use merge-mining in any of its variant forms. Secondly, it uses multisig and escrow bonds to create a second layer proof-of-stake system on top of Bitcoin. Third, it does not require any changes to Bitcoin in order to deploy.
The first thing to clarify is that, technically speaking, the spiderchain isn’t really the sidechain. Any sidechain deployed utilizing spiderchains would sit “above” the spiderchain which sits above the base layer on the mainchain. Sidechain blocks would be produced independently by the stakers (referred to as orchestrators in the paper) in the consensus system. The spiderchain, rather than being the actual sidechain, is a sort of collateral layer facilitating the custody of users’ funds and stakers bonds on the mainchain. Think of it like the middle of the sandwich between the sidechain and the mainchain.
The Proof of Stake Variant
To get a better idea of how the system works, let’s go through how the Botanix EVM chain interacts with the spiderchain layer. One of the first uses the system makes of the Bitcoin blockchain aside from actually custodying funds backing the sidechain tokens is the selection of a block constructor. Proof-of-stake chains require a selection process for which staker actually puts blocks together from the transactions in the mempool. In proof-of-work all miners do this independently and whoever gets lucky and finds a valid blockheader hash has their block accepted into the blockchain. Since the entire point of proof-of-stake is to do away with energy intensive randomizing of who selects the next block, these systems need another solution. They use a Verifiable Random Function (VRF), a function that allows all participants to verify the outcome is actually random and not biased or deterministic. Spiderchains make use of Bitcoin blockhashes in order to acquire verifiable randomness.
Just like other proof-of-stake systems Botanix divides the blockchain into discrete sections called “epochs” which are finalized periodically and a new block constructor is chosen. At the start of an epoch the mainchain blockhash is taken and applied as a source of randomness to all the stakers to choose the new block constructor. After six blocks, to account for the possibility of reorgs, the network transitions to the new block constructor for that epoch. Now this describes the way the proof-of-stake system handles block construction on the sidechain and reaching consensus on whose turn it is, time to get to how this all interacts with the spiderchain (and what exactly a spiderchain is).
The Spiderchain
In addition to using it periodically for selecting a block constructor, the sidechain also utilizes the VRF to select a random subset of the stakers to construct a multisig address for deposits into the sidechain every single Bitcoin block. That’s right, a random set of members for the peg’s multisig. Unlike a federated sidechain, which custodies funds in addresses composed of the entire set of the federation membership, spiderchains break each deposit (or change from transactions pegging out of the sidechain) off into a unique address depending on the mainchain block it confirms in made up of a random subset of the set of stakers. I.e. If there are 50 people staking at any given blockheight, 10 are randomly selected to be key holders for any deposits occurring in the next block. This may intuitively seem rather crazy, but there are a few sound logical reasons for it.
It segregates risk of funds from malicious parties. Most people think of theft, but even loss of liveness can be a disaster for systems like this. Think of a federated sidechain, you don’t need a malicious majority to cause a massive problem, just a malicious minority. If a federation requires a 2/3rds threshold to move coins, then just 1/3rd + 1 member is enough to keep those coins frozen (this is why Liquid has a time-delayed emergency recovery path with Blockstream held keys to prevent permanent coin loss in this situation). You don’t even need any malicious actors strictly speaking, just key loss could create that problem. By breaking up deposits into isolated subset keys with random members, you mitigate (not solve) problems like this. If keys were lost, or a malicious actor was able to gain enough staking percentage in the system to stall or steal, they statistically will never have access to the entirety of the funds in the spiderchain. Each block has totally independent odds of constructing a deposit address controlled by a malicious majority (or impleded by a malicious minority), and if those conditions are met only the funds deposited or rolled over through change from withdrawals in that specific block will be at risk instead of the entirety of the sidechain’s funds.
There is also another interesting security property that derives from how withdrawals are handled. Any sidechain peg mechanism that doesn’t aggregate all deposits into a single rolling UTXO begs the question of which UTXOs to use for fulfilling withdrawals. The spiderchain design has settled on Last In First Out (LIFO), 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 the set of stakers in order to steal funds from the spiderchain. All the money that was deposited before those malicious entities become a majority is completely safe and firewalled from them until any withdrawal requirements start necessitating spending those funds and rotating the change into new addresses. Now, even after they are the majority of stakers, they will only have access to funds where they randomly wind up as the majority of the key members in the deposit address creation protocol. So even after they have entered and taken over so to say, they will not have full access to all funds deposited after that fact because of the deposit address creation using a VRF.
This chain of randomly constructed multisigs is the spiderchain, the pegging mechanism used to lock and unlock coins into and out of the sidechain.
The Staking Bonds
The last piece of any proof-of-stake system is bonds, and it’s pretty simple. If stakers aren’t required to put anything up for collateral in exchange for participation in the consensus mechanism, then there is nothing that can be taken from them as a penalty for malicious behavior. This is accomplished by, you guessed it, using the spiderchain. The same way deposit addresses are generated for users, each block a new deposit address is generated for people who want to stake on the sidechain to deposit a bond into a multisig composed of a random set of existing stakers. Once this bond is confirmed, the new member is recognized as a staker and included in the overall set that new block constructors and deposit address members are selected from.
At that point, if a staker fails to respond and stay online or engages in malicious behavior they can be penalized through slashing and if necessary ultimately removed from the set of stakers by slashing the entire staking bond. The nice thing about the way this is done is the slashing policy, i.e. the amount in penalties for specific actions or misbehaviors, is not programmatic or social, it’s both. Slashing occurs programmatically on the base layer of the mainchain, but is initiated socially by the keyholders of a staking bond. This means there is potential for things to be a little messy, but flexibility to finetune things to an equilibrium that keeps things functioning in a way beneficial to stakers and users.
Gluing It All Together
Take the idea of proof-of-stake as a base layer consensus mechanism, and throw the idea away for right now. That’s not what this is, and the problems that need to be solved to enable proof-of-stake as a second layer system instead of a stand alone base layer are not the same. Proof-of-stake is essentially a federation, but where anyone can join and can’t be stopped from doing so, and with a mechanism to punish members for acting malicious. As a base layer that creates all kinds of existential issues, like the objectivity of a slashing penalty. Proof-of-stake as a second layer does not have that problem when the bonds for slashing are on the mainchain, governed by proof-of-work.
The problem with proof-of-stake as a second layer is how do you guarantee that new members cannot be kept out of the “federation.” If all the funds are custodied by the current members, a majority (or malicious minority of 1/3rd + 1) could prevent any funds from being transferred to a multisig with new members included. They could be stopped from joining. The way that deposits and staking bonds make use of the spiderchain, and it’s provably randomly generated multisigs composed of subgroups of the “federation”, it elegantly solves that problem of current members being able to exclude new members. Everything governing the address members and new entrants is provably verifiable and enforced by second layer consensus with information viewable on the mainchain governed by proof-of-work. Once someone posts a bond, they’re part of the set that gets selected to custody deposits and other staking bonds. It’s all there and verifiable.
It also creates some interesting security properties and dynamics based on how it works. In a federated sidechain the instant funds were rotated into multisigs composed of enough malicious entities the entirety of the sidechains funds are compromised. With a spiderchain, the entrance of a new malicious majority can be almost completely mitigated if it is recognized quickly. Just ceasing new deposits until slashing can trim out enough malicious participants can keep the amount of funds at risk limited to the statistical portion of new deposits that wound up in addresses they control since they became the majority. They would be unable to slash any old staking bonds from before their entrance, but pre-existing members would be able to statistically slash a portion of their bonds.
As long as the size of individual multisigs are balanced right with the total number of stakers, and the value of all deposits compared with staking bonds, this could be a very workable system.
Overall it is 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, mechanisms for protecting against malicious members, and an incentive to participate because the stakers can split transaction fees. The kicker? Why should you care? It doesn’t require any fork at all to enable, so it’s going to happen.
Leave a Reply