How ‘Spiderchain’ Plans to Build Ethereum on Bitcoin

Fol­low­ing weeks of debate about Bit­coin dri­vechains, a sim­i­lar project to unlock the network’s pro­gram­ming poten­tial is pick­ing up steam.

On Mon­day, Jame­son Lopp—co-founder and CTO of mobile self-cus­tody firm Casa—published a blog post about “Spi­der­chain,” which he called “yet anoth­er pro­pos­al for build­ing 2‑way pegged sidechains.”

A sidechain is a sep­a­rate blockchain that is tied into the main Bit­coin net­work in some way. They typ­i­cal­ly use the same native currency—BTC—and may also lever­age Bitcoin’s secu­ri­ty guar­an­tees. Sidechains let Bit­coin­ers access more fea­tures with their BTC that the main net­work can’t always pro­vide, such as scal­a­bil­i­ty, pro­gram­ma­bil­i­ty, and privacy.

A pre­vail­ing dif­fi­cul­ty with sidechains, how­ev­er, is build­ing a “2‑way peg” allow­ing BTC to be safe­ly trans­ferred to the sidechain and back with­out requir­ing a cen­tral­ized middleman.

That’s where the Spi­der­chain, devel­oped by Botanix Labs, comes into play. 

“The Spi­der­chain works as a Proof of Stake Lay­er 2 on Bit­coin,” Willem Schroé, founder of Botanix Labs, told Decrypt. “You stake Bit­coin on Bit­coin in decen­tral­ized mul­ti­sigs.”

Enti­ties that man­age decen­tral­ized mul­ti­sigs are called “orches­tra­tors,” who run both a Bit­coin node and a Spi­der­chain node. With every request to move BTC to the Spi­der­chain, a new mul­ti­sig is cre­at­ed that’s con­trolled by a ran­dom sub­set of 100 par­tic­i­pants with­in the stak­er set.

In many ways, the Spi­der­chain oper­ates much like Ethereum: it is Ethereum Vir­tu­al Machine-com­pat­i­ble, has 12-sec­ond block times, and uses a proof of stake con­sen­sus mech­a­nism to secure the net­work, where­by orches­tra­tor nodes must stake BTC to participate. 

Its EVM is also “ful­ly equiv­a­lent,” mean­ing exist­ing Ethereum dapps can be eas­i­ly trans­ferred over to the net­work by devel­op­ers. But unlike Ethereum, Schroé said that a mali­cious major­i­ty of orches­tra­tors still can­not con­spire to steal users’ BTC. 

“The design is pos­si­ble on the cur­rent Bit­coin core, so no soft fork or upgrade is need­ed,” not­ed Schroé. This sets Spi­der­chain apart from Paul Sztorc’s dri­vechain pro­pos­al, which requires chang­ing the Bit­coin code that users and min­ers are cur­rent­ly run­ning. 

Dri­vechain was intro­duced as BIP 300 and BIP 301 back in 2015, and is still yet to be wide­ly embraced for imple­men­ta­tion by Bitcoiners. 

Dri­vechains effec­tive­ly put con­trol of pegged BTC into the hands of Bit­coin min­ers, but allow for any num­ber of sidechains with any num­ber of prop­er­ties to be cre­at­ed. It also direct­ly inher­its Bitcoin’s secu­ri­ty through merge min­ing, which pig­gy­backs on the main network’s immense proof of work security.

When asked about Spi­der­chains, Sztorc said they seem “very com­plex” com­pared to his proposal.

“I also think that the whole “needs a change to Bit­coin” is pure super­sti­tion, unfor­tu­nate­ly,” he added. “Peo­ple think it means ‘the net­work’ must upgrade, but real­ly it is like ask­ing users to install an app on their phone.”

In Lopp’s Mon­day blog post, the CTO cit­ed the near­ly decade-old Root­stock pro­pos­al, and point­ed out some tech­ni­cal vul­ner­a­bil­i­ties with Spi­der­chain. Among them is the risk that its BTC peg is “bro­ken” if the main Bit­coin blockchain expe­ri­ences a reorg of longer than five blocks, due to the sys­tem by which Spi­der­chain orches­tra­tors are deter­mined.

“It would be unlike­ly to be cat­a­stroph­ic due to how the funds are dis­persed across many mul­ti-sig wal­lets,” he not­ed.

Schroé also admit­ted that in the network’s ear­ly stages, Spi­der­chain will be cen­tral­ized until more users can come in to stake their BTC. “We need to start off cen­tral­ized in the sense that ini­tial­ly we will have to make the stak­ing per­mis­sioned,” he said.