[Discussion] Spiderchains

[OmegaStarScream]

So I have been seeing a few articles about "Spiderchains"[1][2] lately, which is meant to be a Proof-of-stake L2 solution for Bitcoin. I still haven't done much reading about it, but I thought it would be a good idea to share it here since I didn't see any discussion about it.

The network is still not open to the public yet,  but you can join the waitlist from the official site. And for those interested in reading about it (technical) you can start here[3].

[1] https://decrypt.co/197687/how-spiderchain-plans-to-build-ethereum-on-bitcoin
[2] https://bitcoinmagazine.com/technical/spiderchains-a-proof-of-stake-second-layer
[3] https://docs.botanixlabs.xyz/botanix-labs/

[1714639546]

1714639546

[1714639546]

1714639546

[1714639546]

1714639546

[1714639546]

1714639546

[1714639546]

1714639546

[WillyAp]

So I have been seeing a few articles about "Spiderchains"[1][2] lately, which is meant to be a Proof-of-stake L2 solution for Bitcoin.

I wasn't aware that Bitcoin had a L2 Problem. It was built as a P2P and that it does OK

Surely there are a lot of people holding eth and wish to convert them to bitcoin.

POS was discussed:
https://coingeek.com/bitcoin-class-with-satoshi-proof-of-work-vs-proof-of-stake/
I don't think choosing POS was a smart move.

[robelneo]

There's a possibility that this concept will materialize because there is no fork or upgrade needed compared to other proposals but the biggest question is will many people get in because they will start as centralized.

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.

Let's see how this will evolve and whether will it be accepted by the majority of the community

[d5000]

Interesting. It seems that this year really something is moving when talking about sidechains.

These spiderchains at the very first glance (have to investigate more) look a bit similar to a model @vjudeu proposed a couple of months ago in the Drivechain thread (from this post on, it's detailed later).

There is also Nomic, which looks a bit similar too and seems to be already working, and Stacks (sBTC), which is in alpha state (I erroneously thought it was already working, but no).

And Trustless Computer (which comes out of the ... Ordinals community  ) could also be mentioned, although I'm quite sceptical in this case, it seems difficult to find information how it really works (in theory it's an Optimistic Rollup). Perhaps it's ... not really a solution (to not write the S-word).

PS: The Bitcoin Magazine article explains a bit more about the technical side. It looks like there are some similarities to the Stacks/Nomic system of "dynamic federations": The spiderchain (PoS) stakers select randomly a subset of their addresses as a multisig federation on the Bitcoin main chain, which is renewed each block (so we have 1 Bitcoin tx per sidechain per block, if I understand correctly). These multisig federations decide, by majority, about peg-ins and peg-outs, and if some of the stakers misbehave they're slashed at the spiderchain. I've not completely understood why there is a "third" layer mentioned (mainchain -> spiderchain -> sidechain) but maybe the "third layer" isn't really a layer but only the "Bitcoin-pegged token" which lives at the spiderchain.

[WillyAp]

It's sidechain and doesn't require any change on Bitcoin protocol, so even it's failed it won't have noticeable impact on Bitcoin.

If it fails it has a great impact on prices of many coins riding on POS.
Surely some damage will spill over.

[d5000]

[PoS] require Spiderchain to be popular in first place.

I think security is really a challenge in this sidechain model. The native token of the sidechain has to be quite valuable if they want to ensure the incentive mechanism prevents them to steal money via fake peg-ins/peg-outs.

There could even be a formula for that: the slashing penalty for the qualified majority of the selected subset of stakers which manages the peg in a block has to be higher than the maximum expected total Bitcoin peg-in/peg-out transfer. If this wasn't the case, a big whale could simply buy a lot of staking nodes and then wait for his nodes being selected as the majority of the staking nodes, then stealing all the Bitcoins or alternatively stalling the process and short the sidechain token. Both attacks would be catastrophic for the Spiderchain probably.

So the value the sidechain is able to manage safely depends directly on the market cap of the native Spiderchain token, and of the slashing value. Of course, for PoW sidechains a similar rule applies, but Drivechains seem to be a bit more secure as they require cooperation from mainchain miners.

Perhaps with this in mind, it would be recommendable to start not pegging a token to Bitcoin but to some altcoin instead, so the spiderchain can demostrate it works with low peg-in/peg-out volumes, and then slowly increase its value and then finally offer a Bitcoin peg once a certain level has been reached.

[NotATether]

PS: The Bitcoin Magazine article explains a bit more about the technical side. It looks like there are some similarities to the Stacks/Nomic system of "dynamic federations": The spiderchain (PoS) stakers select randomly a subset of their addresses as a multisig federation on the Bitcoin main chain, which is renewed each block (so we have 1 Bitcoin tx per sidechain per block, if I understand correctly).

The consensus layer of that protocol must use something other than wealth to organize the selection of addresses, otherwise power can be unfairly shifted towards whales, BlackRocks, and other deep pockets. I suggest something like what has been done in the bitcoin core base - hardcore a list of trusted addresses, and make a supplementary "DNS service" for finding the address for someone on this protocol, so that you have all these addresses connecting to each other and that the distribution in the multisig is random.

[Yamane_Keto]

I still have not seen how 2-way peg will be decentralized, as the network still needs a completely central intermediary in the first stage, and even if it is developed, it will be a distributed network of orchestrators with a limited number (the number cannot be greatly increased due to the volume of multiple signatures). It is closer because It will be decentralized and distributed. It is true that it will be much better than alternative currencies, but pegged 1:1 with BTC with blocks being mined every 12 seconds will create a finality problem.

The real challenge is their success in attracting a large number of Orchestrator nodes running. If this happens, then this may change, as spiderchains  are compatible with EVM, and it may mean attracting more projects.

[NotATether]

I still have not seen how 2-way peg will be decentralized, as the network still needs a completely central intermediary in the first stage, and even if it is developed, it will be a distributed network of orchestrators with a limited number (the number cannot be greatly increased due to the volume of multiple signatures). It is closer because It will be decentralized and distributed. It is true that it will be much better than alternative currencies, but pegged 1:1 with BTC with blocks being mined every 12 seconds will create a finality problem.

I don't like the idea of having a peg, because that tends to imply "here are two different coins you can trade separately" which is usually the case for other pegs.

But if there's one particular way I think it should be done, it is how Lightning Network did it. Nobody is arbitraging LNBTC and BTC, because everyone knows they're just Bitcoin. The supply of LNBTC eventually goes back into the BTC mainnet.

[Yamane_Keto]

I don't like the idea of having a peg, because that tends to imply "here are two different coins you can trade separately" which is usually the case for other pegs.

It is true that it is not a 1:1 connection and is not dependent on a third party (BitGo) as in the case of pegged tokens, but any Orchestrator will receive a slashing reward as long as this equation is adhered to:

BTC secured< ((4n^2)*s)/9 where n = number of signers and s = stake size per orchestrator

With this equation, we can say that if there were 5 signatories, each staking 5 BTC, then the maximum “safe” amount of Bitcoin in the multi-signature would be ~56 BTC, which is not good since their total Bitcoin is 25 BTC.

But if there are 30 signers each staking 30 BTC, you will find that the “safe” amount is ~12,500 BTC while the currencies being bet with are 900 BTC.

So the more Orchestrator nodes there are, the smaller the probability of having a large number of malicious Orchestrators in the same multisig.
But the question is what would anyone pay to run an Orchestrator node as income can only be earned from transaction fees which are supposed to be cheaper than on-chain fees.

This is a good explanation https://blog.lopp.net/an-introduction-to-spiderchain/, including the equation above

[d5000]

I don't like the idea of having a peg, because that tends to imply "here are two different coins you can trade separately" which is usually the case for other pegs.[...]The supply of LNBTC eventually goes back into the BTC mainnet.

I don't see that much of a conceptual difference between a 2-way pegged spiderchain token (can be applied to all similar sidechain designs) and LNBTC. In both cases, you have contracts on the mainchain which ensure that the supply is always 1 peggedBTC = 1BTC, and you can describe them as methods to bundle BTC transactions.

On a sidechain/spiderchain, when the "Orchestrators" try to steal coins, this is very similar to a LN member trying to close a channel in an old state. Nothing is changed regarding the token supply, but there is an unintended ownership change which would not be possible only using on-chain methods.

The only difference I see is that a sidechain in theory could be buggy in the sense that some unintended function leads to a supply inflation of the pegged token (let's say something like the Bitcoin overflow bug in 2010). From my limited understanding that would not be possible in LN, not even taking into account milisats, but all sidechains have this theoretical problem. As long as they work as expected though that's not a problem. Where a difference could be possible is if the sidechain stakers cooperate to create such a bug intentionally. This would however damage all Orchestrators, because they couldn't exit 1:1 anymore. So the attacking subset would have to profit purely by operations on the sidechain (e.g. fast sells of the sidechain tokens on exchanges, or buying goods/services) and I cannot imagine that kind of attack to be easy to be profitable as long as the sidechain isn't extremely popular (and of course, it would be detected in one block as a maximum).

This little drawback however is compensated by the big advantage that you can "onboard" people completely independently of mainchain transactions.