How ‘Spiderchain’ Plans to Build Ethereum on Bitcoin

Following weeks of debate about Bitcoin drivechains, a similar project to unlock the network’s programming potential is picking up steam.

On Monday, Jameson Lopp—co-founder and CTO of mobile self-custody firm Casa—published a blog post about “Spiderchain,” which he called “yet another proposal for building 2-way pegged sidechains.”

A sidechain is a separate blockchain that is tied into the main Bitcoin network in some way. They typically use the same native currency—BTC—and may also leverage Bitcoin’s security guarantees. Sidechains let Bitcoiners access more features with their BTC that the main network can’t always provide, such as scalability, programmability, and privacy.

A prevailing difficulty with sidechains, however, is building a “2-way peg” allowing BTC to be safely transferred to the sidechain and back without requiring a centralized middleman.

That’s where the Spiderchain, developed by Botanix Labs, comes into play. 

“The Spiderchain works as a Proof of Stake Layer 2 on Bitcoin,” Willem Schroé, founder of Botanix Labs, told Decrypt. “You stake Bitcoin on Bitcoin in decentralized multisigs.”Entities that manage decentralized multisigs are called “orchestrators,” who run both a Bitcoin node and a Spiderchain node. With every request to move BTC to the Spiderchain, a new multisig is created that’s controlled by a random subset of 100 participants within the staker set.

In many ways, the Spiderchain operates much like Ethereum: it is Ethereum Virtual Machine-compatible, has 12-second block times, and uses a proof of stake consensus mechanism to secure the network, whereby orchestrator nodes must stake BTC to participate.

Its EVM is also “fully equivalent,” meaning existing Ethereum dapps can be easily transferred over to the network by developers. But unlike Ethereum, Schroé said that a malicious majority of orchestrators still cannot conspire to steal users’ BTC. 

“The design is possible on the current Bitcoin core, so no soft fork or upgrade is needed,” noted Schroé. This sets Spiderchain apart from Paul Sztorc’s drivechain proposal, which requires changing the Bitcoin code that users and miners are currently running.  Drivechain was introduced as BIP 300 and BIP 301 back in 2015, and is still yet to be widely embraced for implementation by Bitcoiners.

Drivechains effectively put control of pegged BTC into the hands of Bitcoin miners, but allow for any number of sidechains with any number of properties to be created. It also directly inherits Bitcoin’s security through merge mining, which piggybacks on the main network’s immense proof of work security.

When asked about Spiderchains, Sztorc said they seem “very complex” compared to his proposal.

“I also think that the whole “needs a change to Bitcoin” is pure superstition, unfortunately,” he added. “People think it means ‘the network’ must upgrade, but really it is like asking users to install an app on their phone.”In Lopp’s Monday blog post, the CTO cited the nearly decade-old Rootstock proposal, and pointed out some technical vulnerabilities with Spiderchain. Among them is the risk that its BTC peg is “broken” if the main Bitcoin blockchain experiences a reorg of longer than five blocks, due to the system by which Spiderchain orchestrators are determined. “It would be unlikely to be catastrophic due to how the funds are dispersed across many multi-sig wallets,” he noted. Schroé also admitted that in the network’s early stages, Spiderchain will be centralized until more users can come in to stake their BTC. “We need to start off centralized in the sense that initially we will have to make the staking permissioned,” he said.