An Introduction to Spiderchain

With all of the recent discussions and drama around drivechains, it seems most folks have overlooked a recent announcement of yet another proposal for building 2-way pegged sidechains.

Botanix Labs recently unveiled itself and published this whitepaper. Since their software is not yet available to run and inspect, the following are my impressions from reading the system as described in the paper.

While there are a variety of proposals being discussed for enhancing Bitcoin's Layer 2 capabilities, such as drivechains, zero knowledge rollups, and validity rollups, one distinction with spiderchains is that they can be implemented on Bitcoin today without any protocol changes to the base layer.

Motivation

Ethereum has seen a massive growth in decentralized finance applications that are mostly unavailable on Bitcoin. The total value on the second layers of Bitcoin is less than 0.1% of the market cap of Bitcoin while at the same time the value of wrapped Bitcoin available on Ethereum is higher than 2%. Bitcoin has not seen the massive growth in TVL (Total value locked) on its second layers or in its applications.

This paper proposes a second layer built on top of Bitcoin with full Ethereum Virtual Machine (EVM) equivalence. With Bitcoin as the most decentralized and secure bottom layer, the second layer will open the doors to the composability, ecosystem and capabilities of Ethereum smart contracts. We introduce the Spiderchain primitive, a second layer design on top of Bitcoin that is optimized for decentralization.

Alright, so we know off the bat that this proposal is going to be for creating a sidechain similar to Rootstock, but with a different pegging mechanism. A reminder from the Pegged Sidechains Whitepaper published in 2014:

A problem is that altchains, like Bitcoin, typically have their own native cryptocurrency, or altcoin, with a floating price. To access the altchain, users must use a market to obtain this currency, exposing them to the high risk and volatility associated with new currencies. Further, the requirement to independently solve the problems of initial distribution and valuation, while at the same time contending with adverse network effects and a crowded market, discourages technical innovation while at the same time encouraging market games. This is dangerous not only to those directly participating in these systems, but also to the cryptocurrency industry as a whole.

Some detractors as of late have been saying that sidechains are useless and there's no demand for them since the two oldest and most notable sidechains, Liquid and Rootstock, haven't gained significant adoption. Yet, it's empirically obvious that there is demand to "use bitcoin" as a unit of account for more complex financial functions. Demand is so high that over 150,000 BTC has been given to a trusted third party custodian (BitGo) to issue BTC pegged tokens for use on Ethereum!

Regardless of what your views might be on sidechains, I contend that continuing research and development of robust permissionless 2-way pegging mechanisms is a worthy pursuit.

"Trusted third parties are security holes."
- Nick Szabo

Introduction

Botanix notes that the Ethereum Foundation’s vision for solving the scalability problem consists of multiple layers of EVM (Ethereum Virtual Machine) compatible chains, with the main chain as a settlement layer at the bottom. But Ethereum still faces centralization questions with multiple hard forks on the roadmap, the role of the Ethereum Foundation, and their move to Proof-of-Stake. Botanix contends that Bitcoin is a more suitable foundation upon which to build second layers since it's extremely difficult to change and is secured by Proof of Work.

Why EVM?

Solidity smart contracts benefit from the Lindy effect and experience higher levels of trust and familiarity. From a programming language perspective, Solidity has a strong footing in the crypto world and Botanix has therefore opted to leverage the tools that already exist in the EVM ecosystem.

The Spiderchain

The Spiderchain peg is a series of successive multisig wallets managed by Orchestrators. A grossly oversimplified explanation of how the system works:

• People deposit BTC collateral into a multisig wallet to run an Orchestrator.
• Orchestrators run 2 nodes side by side: a Bitcoin node and a Spiderchain node.
• Orchestrators manage the peg-in and peg-out requests by controlling the multisig wallets and make sure other Orchestrators are acting honestly and staying active.
• New peg-in requests result in creation of a new multisig wallet managed by a random subset of currently active Orchestrators.
• One specific Orchestrator gets chosen to lead each spiderchain epoch (when a Bitcoin block occurs and peg-ins and outs can happen) based upon the Bitcoin block hash from 6 blocks prior. Each successive spiderchain block is led by a different orchestrator designated via sequential calculations performed upon the same block hash.

This is the image used to visualize the relationship between the spiderchain, bitcoin blockchain, and pools of pegged bitcoin. I think one thing that's missing is that there's not a 1:1 relationship between spiderchain blocks and Bitcoin blocks. Rather, like Ethereum, the spiderchain has blocks every 12 seconds. The first new spiderchain block that is minted after a new Bitcoin block becomes an anchor point and demarcates a new "epoch" on the spiderchain, creating finality for all of the transactions in blocks that came before that point.

Security Model

Botanix has opted for a Proof of Stake consensus model. Since synthetic bitcoin on the spiderchain will be pegged 1:1 with BTC, the centralization trend for the participants seen in PoS will be counterbalanced by Bitcoin’s PoW. However, this also means there will be no base fee reward for the stakers - they can only collect transaction fees and presumably slashed stakes from misbehaving Orchestrators.

Botanix benefits from the security features of Bitcoin’s PoW system and uses these to mitigate the potential vulnerabilities (Centralization, Randomized Validator Selection, Finality) of PoS consensus algorithms.

As long as the number of adversarial collaborating actors is overwhelmed by 2/3 or more honest Orchestrators, the game theory is sound.

For the pegging process, spiderchain offers a new set of trade-offs.

• Federated multisig (funds managed by static consortium)
• Drivechain (funds managed by dynamic signers: miners)
• Spiderchain (funds managed by dynamic stakers)

The sections on UTXO management are interesting given that, unlike other pegged sidechain proposals, spiderchain does not rely upon one single pool of pegged funds. As such, using last-in first-out (LIFO) for peg-outs will ensure the oldest coins are secured by the oldest orchestrators, therefore giving a young malicious adversary no chance to gain control of the older coins

An Orchestrator can deposit bitcoin and after 6 blocks start staking and orchestrating. However, they won't get added to any of the multisig wallets unless a current orchestrator publishes their intent to exit. When an Orchestrator wants to exit, it has to wait for every multisig wallet on which it's a signer to have its key replaced by one of a different, recently joined Orchestrator.

There are four variables that affect in the security level of a spiderchain:

• Size of the multisig (number of signers)
• The stake (collateral) provided by the Orchestrators
• The total number of Orchestrators
• The total bitcoin locked in the Spiderchain

The paper notes that the first two can be controlled at the protocol level. What I'd like to see more of is how they might be dynamically adjusted as the latter two variables change over time. Though I expect this will be a learning process over the coming years as the first spiderchain is bootstrapped.

Assumptions

If any of the following attributes fail to hold, the security of the spiderchain and its pegged bitcoin is in peril.

No one has 50%+ of the funds pegged into the network (staked.)

No single spiderchain multisig contains an adversarial or unresponsive quorum of 33%. If 1/3 of the Orchestrators on any given multisig are uncooperative, it becomes impossible to peg those funds out. Therefore, inactive Orchestrators will no longer receive block rewards, and after one week of inactivity will slowly be removed from the multisigs.

There's also an unstated assumption that Bitcoin will never suffer from a chain reorganization of more than 5 blocks. This is because Orchestrators are determined 6 blocks ahead of time by performing a modulus on the Bitcoin block hash. What happens if a reorg longer than that occurs? Seems like there's potential for the peg to get broken, though it would be unlikely to be catastrophic due to how the funds are dispersed across many multisig wallets.

Goldilocks Numbers

There are many yet-to-be-determined optimal values for the technical and economic variables at play. I believe this is the primary reason why we see a phased bootstrapped process proposed for launching and evolving the spiderchain's security architecture.

Multisig size and coordination. If there are too many signers on a given multisig then it may become too cumbersome to coordinate signatures in a timely manner. If there are too few signers then it's too easy for an attacker to add enough signers to Sybil attack wallets and drain funds.

Stake size and centralization. If the stake size chosen is too big, entities are less inclined to run a node therefore reducing the decentralization. If the stake size is too low, the cost for a malicious entity to produce a Sybil attack might be too low.

Orchestrator liveness. If 1/3 of the signers for any given multisig are unresponsive or otherwise noncompliant, the funds can't be pegged out. If the inactivity period for penalizing misbehaving Orchestrators is too low, it could open up the potential for DoS attacks. If the period is too high, it increases the chance of a multisig's funds being temporarily frozen if not permanently lost.

It seems to me that some of these number should probably be dynamic and should scale along with the size of the spiderchain in terms of total Orchestrators and total BTC pegged into the system.

Capital Efficiency

Is a spiderchain capital efficient with regard to its security requirements? Given:

• x = the BTC secured in a certain multisig
• n = the number of signers on a multisig
• s = the stake size in BTC per orchestrator

A rational Orchestrator will choose to reporting erratic behavior and receive the slashing reward as long as:

What does this mean from a practical standpoint? Let's assume we don't want more than 50 signers on a multisig due to the rising coordination complexity.

If we had a multisig of 10 signers each staking 10 BTC then the maximum "safe" amount for that multisig to manage would be ~420 BTC. Not great since the capital efficiency is only ~ 3X.

If we had a multisig of 30 signers each staking 30 BTC then the maximum "safe" amount for that multisig to manage would be ~12,500 BTC. Not shabby, given that only 900 BTC are at stake. That's a much better ~13X capital efficiency.

Though 50 signers staking 50 BTC would raise the safety ceiling to 55,555 BTC. A ~22X capital efficiency.

Note that in order for these equations to hold true, a relatively high number of Orchestrator nodes must be in operation so that the probability for an adversary attempting a Sybil attack to have multiple Orchestrators in the same multisig is quite low.

Spiderchain Bootstrapping

Botanix seems well aware that there are a lot of variables at play here and it will likely involve experimentation and lessons learned in production to navigate the bootstrapping process. To avoid silent malicious majority attacks, the bootstrapping will happen in 5 phases, with the initial phase being composed of 100% Botanix controlled Orchestrators.

Suffice to say, it looks like a long road from 100% centralized to public permissionless 2 way pegged sidechain. I'm certainly skeptical of any project that presents a roadmap going from centralized to decentralized, because the tendency for anything is to become more centralized over time. Yet, given all of the unknowns involved in this experiment, it does seem that jumping headfirst into a purely permissionless architecture is asking for catastrophe.

Incentives

Why will anyone want to run an Orchestrator honestly? The network itself doesn't generate new tokens, thus stakers can only earn income from transaction fees.

As such, the gas pricing mechanism on the spiderchain is an important economic consideration. Assuming it's the same as Ethereum, and 1 satoshi == 10 gwei and the base transaction fee is 100 gwei (per Ethereum documentation) then the floor base fee on the spiderchain is 10 "synthetic" satoshis for a simple EOA to EOA transfer. For comparison, about the cheapest simple on-chain bitcoin transfer (P2TR) would cost about 150 satoshis at the floor fee rate of 1 satoshi per virtual byte. Point being, it seems like the floor for transaction fees is an order of magnitude lower on the spiderchain than on the base chain. That seems like a decent incentive for transactors to want to use it, but the flip side is that it may prove a more challenging road to bootstrap sustainable fee volume. Of course, this is all speculation and the base fee may very well be set higher on a spiderchain.

Open Questions

The paper seems to assume that every bitcoin block will include spiderchain peg-ins and outs. What happens (if anything) if an Orchestrator fails to publish the agreed-upon UTXO updates for the next Bitcoin block?

What happens if someone requests a peg-in address which, according to the paper, is generated by the current Orchestrator, but they send the bitcoin at a later date OR it doesn't get confirmed quickly due to paying an uncompetitive fee rate? Can these "stale" peg-ins be swept later or is there a risk of funds loss?

Are peg-ins a potential single point of failure if they're only controlled / watched by a single Orchestrator? The paper tells us that "after the peg-in process, the on-chain funds remain secured in multisig chain between the different Orchestrator nodes" but the guarantees for the limbo state of an unconfirmed peg-in are unclear.

If the goal is to prevent fund loss of peg-ins due to delayed confirmation, then it seems like every Orchestrator will need to keep the entire history of peg-in multisig addresses and scan for them at every new Bitcoin block. This might not scale well on a multi-year timeframe.

Similarly, this issue may also exist in reverse for the peg out process, though the scaling concerns would be about 60X higher if the Orchestrator node used to build the peg-out UTXO is a "slot" Orchestrator as opposed to an "epoch" Orchestrator - it's not clear from the paper.

If an Orchestrator publishes an invalid transaction or block, its stake is slashed and... ? I didn't see any details around the economics of slashing and how the funds are distributed.

Based upon the description of Orchestrator entrance / exit and the mechanism to add the most recent Orchestrators to multisigs, it feels like there's potential for gaps. That is, it seems possible for an Orchestrator to never get added to a multisig if a ton of other Orchestrators join the spiderchain shortly after them.

How long does it actually take to peg out? With drivechains it takes months, which provides a ton of time for human intervention in case of an attack. It seems like with Spiderchains it could take as short as a few hours. Shorter timeframes may increase the chance of mining or DoS attacks.

What's the threshold for removing unreliable Orchestrators? From the paper it sounds like a week of 100% inactivity kicks off the removal process. But what if they are simply unreliable and are only active for ~5% of the blocks each week? Sure, their incentive is to be active otherwise they'll lose out on collecting transaction fees, but it seems like there should be a threshold higher than 0% at which an Orchestrator is booted for being unreliable. The paper does say that inactvity "will result in a slow inactivity leak of the stake" but it's unclear if that means a lack of rewards or if their stake actually gets redistributed to the active Orchestrators.

I suspect there are also some gnarly questions around UTXO management with regard to the different multisig wallets. For example, if there's only a limited peg-in window and then funds are later pegged out, but the wallet isn't fully emptied, and new wallets are created for peg-ins, my suspicion is that it's possible to end up with "dust" spread across many multisigs. Thus there's an open question around how much logic will be in place to treat the aggregate of all of the multisig wallets kind of like one large virtual wallet.

Similarly, I wonder how the spiderchain Orchestrators can respond to fee volatility on the base chain. Will they be intelligent enough to RBF / CPFP any stuck peg-outs?

The multisig signature scheme is never mentioned, but I assume it's Schnorr or some sort of construction like MPC that only appears as a single signature on-chain, otherwise the transaction data size and fees will be prohibitively high. Also, Orchestrators need the ability to change the key holders of any given multisig, presumably without having to move funds on-chain.

Potential Attacks

The whitepaper talks about Sybil attacks a fair amount, but it doesn't delve much into some of the issues around liveness. For example, we know that inactive Orchestrators get removed from multisigs after a week of inactivity. What if this attribute was used in conjunction with a denial of service attack? If Orchestrator operators aren't paying attention then they could find themselves knocked out of the system and potentially even lose funds if enough honest Orchestrators are removed as multisig signers.

There may also be a potential attack vector around reorganizing the Bitcoin blockchain. While much ado has been made about the miner voting mechanism used for drivechains, that process takes months to play out while the whole world can observe it. The fact that spiderchains only have a 6 block delay around selecting Orchestrators seems unnecessarily short to me. Personally I'd recommend a 100 block delay to put it in line with the coinbase maturation threshold. On the flip side, given how the spiderchain multisigs are distributed and the LIFO nature of the peg's UTXO management, a short-range attack is more limited in how much of the peg's funds it can affect.

Sidechain Launch Costs

One aspect of pegged sidechains that doesn't get talked about much is the cost of launching one. Recall the original vision of a sidechains universe:

This vision won't be feasible until the launch costs are brought down drastically. From looking at the available options:

• Federated sidechains: high launch costs of organizing a consortium and deploying secure hardware modules for signing.
• Drivechains: medium launch costs of convincing enough miners to cast votes for the peg.
• Spiderchains: unknown launch costs, likely high if long phases of bootstrapping from permissioned to perimissionless are required.

Final Thoughts

We're nearly a decade into the quest for the holy grail of permissionless sidechain pegging and advancement has been rather slow. Thus far we only really have 2 viable options:

1. Distribute trust amongst a sufficiently large federation of reputable entities.
2. Create game theory to manage a pool of pegged BTC. Drivechains creates incentives for miners to manage the BTC while Spiderchains creates incentives for stakers to manage the BTC. Each has trade-offs and complexity.

At a high level, I think that Spiderchain make sense when the conditions are as described in the whitepaper. The million bitcoin question is how well the system can hold up to edge cases and adversarial conditions. The complexity and multi-variate game theory makes it challenging to reason about, and these kinds of economic security systems can't really be played out on a zero value testnet.

I look forward to seeing this experiment progress!