Spiderchains: A Proof Of Stake Second Layer

Please fol­low and like us:

 This is an exten­sion to my pre­vi­ous arti­cle series dis­cussing the dif­fer­ent sidechain pro­pos­als that exist. Those arti­cles can be found here: Spacechains, Spacechain Use Cas­es, Softchains, Dri­vechains, Fed­er­at­ed Chains, and Trade Offs Of Sidechains.

Botanix Labs has pro­posed a com­plete­ly new sidechain design recent­ly, called spi­der­chains, for the pur­pos­es of port­ing the Ethereum Vir­tu­al Machine to a plat­form anchored to the Bit­coin net­work. The archi­tec­ture is a pret­ty large devi­a­tion from most pri­or pro­pos­als for con­crete designs. First­ly, it does not involve min­ers direct­ly in con­sen­sus or use merge-min­ing in any of its vari­ant forms. Sec­ond­ly, it uses mul­ti­sig and escrow bonds to cre­ate a sec­ond lay­er proof-of-stake sys­tem on top of Bit­coin. Third, it does not require any changes to Bit­coin in order to deploy. 

The first thing to clar­i­fy is that, tech­ni­cal­ly speak­ing, the spi­der­chain isn’t real­ly the sidechain. Any sidechain deployed uti­liz­ing spi­der­chains would sit “above” the spi­der­chain which sits above the base lay­er on the main­chain. Sidechain blocks would be pro­duced inde­pen­dent­ly by the stak­ers (referred to as orches­tra­tors in the paper) in the con­sen­sus sys­tem. The spi­der­chain, rather than being the actu­al sidechain, is a sort of col­lat­er­al lay­er facil­i­tat­ing the cus­tody of users’ funds and stak­ers bonds on the main­chain. Think of it like the mid­dle of the sand­wich between the sidechain and the mainchain. 

The Proof of Stake Variant

To get a bet­ter idea of how the sys­tem works, let’s go through how the Botanix EVM chain inter­acts with the spi­der­chain lay­er. One of the first uses the sys­tem makes of the Bit­coin blockchain aside from actu­al­ly cus­tody­ing funds back­ing the sidechain tokens is the selec­tion of a block con­struc­tor. Proof-of-stake chains require a selec­tion process for which stak­er actu­al­ly puts blocks togeth­er from the trans­ac­tions in the mem­pool. In proof-of-work all min­ers do this inde­pen­dent­ly and who­ev­er gets lucky and finds a valid block­head­er hash has their block accept­ed into the blockchain. Since the entire point of proof-of-stake is to do away with ener­gy inten­sive ran­dom­iz­ing of who selects the next block, these sys­tems need anoth­er solu­tion. They use a Ver­i­fi­able Ran­dom Func­tion (VRF), a func­tion that allows all par­tic­i­pants to ver­i­fy the out­come is actu­al­ly ran­dom and not biased or deter­min­is­tic. Spi­der­chains make use of Bit­coin block­hash­es in order to acquire ver­i­fi­able randomness. 

Just like oth­er proof-of-stake sys­tems Botanix divides the blockchain into dis­crete sec­tions called “epochs” which are final­ized peri­od­i­cal­ly and a new block con­struc­tor is cho­sen. At the start of an epoch the main­chain block­hash is tak­en and applied as a source of ran­dom­ness to all the stak­ers to choose the new block con­struc­tor. After six blocks, to account for the pos­si­bil­i­ty of reorgs, the net­work tran­si­tions to the new block con­struc­tor for that epoch. Now this describes the way the proof-of-stake sys­tem han­dles block con­struc­tion on the sidechain and reach­ing con­sen­sus on whose turn it is, time to get to how this all inter­acts with the spi­der­chain (and what exact­ly a spi­der­chain is). 

The Spi­der­chain

In addi­tion to using it peri­od­i­cal­ly for select­ing a block con­struc­tor, the sidechain also uti­lizes the VRF to select a ran­dom sub­set of the stak­ers to con­struct a mul­ti­sig address for deposits into the sidechain every sin­gle Bit­coin block. That’s right, a ran­dom set of mem­bers for the peg’s mul­ti­sig. Unlike a fed­er­at­ed sidechain, which cus­todies funds in address­es com­posed of the entire set of the fed­er­a­tion mem­ber­ship, spi­der­chains break each deposit (or change from trans­ac­tions peg­ging out of the sidechain) off into a unique address depend­ing on the main­chain block it con­firms in made up of a ran­dom sub­set of the set of stak­ers. I.e. If there are 50 peo­ple stak­ing at any giv­en block­height, 10 are ran­dom­ly select­ed to be key hold­ers for any deposits occur­ring in the next block. This may intu­itive­ly seem rather crazy, but there are a few sound log­i­cal rea­sons for it. 

It seg­re­gates risk of funds from mali­cious par­ties. Most peo­ple think of theft, but even loss of live­ness can be a dis­as­ter for sys­tems like this. Think of a fed­er­at­ed sidechain, you don’t need a mali­cious major­i­ty to cause a mas­sive prob­lem, just a mali­cious minor­i­ty. If a fed­er­a­tion requires a 2/3rds thresh­old to move coins, then just 1/3rd + 1 mem­ber is enough to keep those coins frozen (this is why Liq­uid has a time-delayed emer­gency recov­ery path with Block­stream held keys to pre­vent per­ma­nent coin loss in this sit­u­a­tion). You don’t even need any mali­cious actors strict­ly speak­ing, just key loss could cre­ate that prob­lem. By break­ing up deposits into iso­lat­ed sub­set keys with ran­dom mem­bers, you mit­i­gate (not solve) prob­lems like this. If keys were lost, or a mali­cious actor was able to gain enough stak­ing per­cent­age in the sys­tem to stall or steal, they sta­tis­ti­cal­ly will nev­er have access to the entire­ty of the funds in the spi­der­chain. Each block has total­ly inde­pen­dent odds of con­struct­ing a deposit address con­trolled by a mali­cious major­i­ty (or impled­ed by a mali­cious minor­i­ty), and if those con­di­tions are met only the funds deposit­ed or rolled over through change from with­drawals in that spe­cif­ic block will be at risk instead of the entire­ty of the sidechain’s funds. 

There is also anoth­er inter­est­ing secu­ri­ty prop­er­ty that derives from how with­drawals are han­dled. Any sidechain peg mech­a­nism that does­n’t aggre­gate all deposits into a sin­gle rolling UTXO begs the ques­tion of which UTX­Os to use for ful­fill­ing with­drawals. The spi­der­chain design has set­tled on First In First Out (FIFO), mean­ing that any with­drawals from the sidechain will be processed using the most recent­ly deposit­ed UTX­Os. Think of this in the con­text of mali­cious enti­ties join­ing the set of stak­ers in order to steal funds from the spi­der­chain. All the mon­ey that was deposit­ed before those mali­cious enti­ties become a major­i­ty is com­plete­ly safe and fire­walled from them until any with­draw­al require­ments start neces­si­tat­ing spend­ing those funds and rotat­ing the change into new address­es. Now, even after they are the major­i­ty of stak­ers, they will only have access to funds where they ran­dom­ly wind up as the major­i­ty of the key mem­bers in the deposit address cre­ation pro­to­col. So even after they have entered and tak­en over so to say, they will not have full access to all funds deposit­ed after that fact because of the deposit address cre­ation using a VRF. 

This chain of ran­dom­ly con­struct­ed mul­ti­sigs is the spi­der­chain, the peg­ging mech­a­nism used to lock and unlock coins into and out of the sidechain. 

The Stak­ing Bonds

The last piece of any proof-of-stake sys­tem is bonds, and it’s pret­ty sim­ple. If stak­ers aren’t required to put any­thing up for col­lat­er­al in exchange for par­tic­i­pa­tion in the con­sen­sus mech­a­nism, then there is noth­ing that can be tak­en from them as a penal­ty for mali­cious behav­ior. This is accom­plished by, you guessed it, using the spi­der­chain. The same way deposit address­es are gen­er­at­ed for users, each block a new deposit address is gen­er­at­ed for peo­ple who want to stake on the sidechain to deposit a bond into a mul­ti­sig com­posed of a ran­dom set of exist­ing stak­ers. Once this bond is con­firmed, the new mem­ber is rec­og­nized as a stak­er and includ­ed in the over­all set that new block con­struc­tors and deposit address mem­bers are select­ed from. 

At that point, if a stak­er fails to respond and stay online or engages in mali­cious behav­ior they can be penal­ized through slash­ing and if nec­es­sary ulti­mate­ly removed from the set of stak­ers by slash­ing the entire stak­ing bond. The nice thing about the way this is done is the slash­ing pol­i­cy, i.e. the amount in penal­ties for spe­cif­ic actions or mis­be­hav­iors, is not pro­gram­mat­ic or social, it’s both. Slash­ing occurs pro­gram­mat­i­cal­ly on the base lay­er of the main­chain, but is ini­ti­at­ed social­ly by the key­hold­ers of a stak­ing bond. This means there is poten­tial for things to be a lit­tle messy, but flex­i­bil­i­ty to fine­tune things to an equi­lib­ri­um that keeps things func­tion­ing in a way ben­e­fi­cial to stak­ers and users.

Glu­ing It All Together

Take the idea of proof-of-stake as a base lay­er con­sen­sus mech­a­nism, and throw the idea away for right now. That’s not what this is, and the prob­lems that need to be solved to enable proof-of-stake as a sec­ond lay­er sys­tem instead of a stand alone base lay­er are not the same. Proof-of-stake is essen­tial­ly a fed­er­a­tion, but where any­one can join and can’t be stopped from doing so, and with a mech­a­nism to pun­ish mem­bers for act­ing mali­cious. As a base lay­er that cre­ates all kinds of exis­ten­tial issues, like the objec­tiv­i­ty of a slash­ing penal­ty. Proof-of-stake as a sec­ond lay­er does not have that prob­lem when the bonds for slash­ing are on the main­chain, gov­erned by proof-of-work. 

The prob­lem with proof-of-stake as a sec­ond lay­er is how do you guar­an­tee that new mem­bers can­not be kept out of the “fed­er­a­tion.” If all the funds are cus­todied by the cur­rent mem­bers, a major­i­ty (or mali­cious minor­i­ty of 1/3rd + 1) could pre­vent any funds from being trans­ferred to a mul­ti­sig with new mem­bers includ­ed. They could be stopped from join­ing. The way that deposits and stak­ing bonds make use of the spi­der­chain, and it’s prov­ably ran­dom­ly gen­er­at­ed mul­ti­sigs com­posed of sub­groups of the “fed­er­a­tion”, it ele­gant­ly solves that prob­lem of cur­rent mem­bers being able to exclude new mem­bers. Every­thing gov­ern­ing the address mem­bers and new entrants is prov­ably ver­i­fi­able and enforced by sec­ond lay­er con­sen­sus with infor­ma­tion view­able on the main­chain gov­erned by proof-of-work. Once some­one posts a bond, they’re part of the set that gets select­ed to cus­tody deposits and oth­er stak­ing bonds. It’s all there and verifiable. 

It also cre­ates some inter­est­ing secu­ri­ty prop­er­ties and dynam­ics based on how it works. In a fed­er­at­ed sidechain the instant funds were rotat­ed into mul­ti­sigs com­posed of enough mali­cious enti­ties the entire­ty of the sidechains funds are com­pro­mised. With a spi­der­chain, the entrance of a new mali­cious major­i­ty can be almost com­plete­ly mit­i­gat­ed if it is rec­og­nized quick­ly. Just ceas­ing new deposits until slash­ing can trim out enough mali­cious par­tic­i­pants can keep the amount of funds at risk lim­it­ed to the sta­tis­ti­cal por­tion of new deposits that wound up in address­es they con­trol since they became the major­i­ty. They would be unable to slash any old stak­ing bonds from before their entrance, but pre-exist­ing mem­bers would be able to sta­tis­ti­cal­ly slash a por­tion of their bonds. 

As long as the size of indi­vid­ual mul­ti­sigs are bal­anced right with the total num­ber of stak­ers, and the val­ue of all deposits com­pared with stak­ing bonds, this could be a very work­able system.

Over­all it is a very inter­est­ing pro­pos­al that pro­pos­es inter­est­ing solu­tions to the prob­lems of “upgrad­ing” fed­er­a­tions to a proof-of-stake sys­tem: the abil­i­ty for any­one to join, mech­a­nisms for pro­tect­ing against mali­cious mem­bers, and an incen­tive to par­tic­i­pate because the stak­ers can split trans­ac­tion fees. The kick­er? Why should you care? It does­n’t require any fork at all to enable, so it’s going to happen. 

Source link

Please fol­low and like us: