By Bitcoin Magasin - 4 måneder siden - Læsetid: 5 minutter
Mercury Layer: En massiv forbedring af statskæder
CommerceBlock is releasing Mercury Layer today, an improved version of their variation of a statechain. You can read a longer form explanation of how their Mercury statechains work link.. The upgrade to Mercury Layer represents a massive improvement against the initial statechain implementation, however unlike the initial Mercury Wallet release, this is not packaged as a fully consumer ready wallet. It is being released as a library and CLI tool other wallets can integrate. Here’s a quick summary of how they work:
Statskæder er i det væsentlige analoge med betalingskanaler på mange måder, dvs. de er en fælles UTXO med en forudsigneret transaktion som en sidste udvej for folk til at håndhæve deres ejerskab. Den største forskel mellem en Lightning-kanal og en statskæde er de parter, der er involveret i at dele UTXO'en i fællesskab, og hvordan ejendomsretten til et eksigibelt krav mod det overføres til andre parter.
I modsætning til en Lightning-kanal, som oprettes og deles mellem to statiske deltagere, åbnes en tilstandskæde med en facilitator/operatør og kan frit overføres i sin helhed mellem alle to deltagere, der er villige til at stole på, at operatøren skal være ærlig, helt off -kæde. En person, der ønsker at indlæse en tilstandskæde, samarbejder med operatøren for at skabe en enkelt offentlig nøgle, som både skaberen og operatøren har en andel af den tilsvarende private nøgle, uden at nogen af dem har en komplet kopi af nøglen. Herfra underskriver de på forhånd en transaktion, der giver skaberen mulighed for ensidigt at kræve deres mønter tilbage efter en tidslås.
For at overføre en tilstandskæde samarbejder den nuværende ejer med modtageren og operatøren for at underskrive et kryptografisk bevis med deres nøgledeling på, at de overfører mønten, og derefter genererer modtageren og operatøren et nyt par nøgledelinger, der lægger op til den samme private nøgle og tegn. en tidslåst transaktion for den nye ejer med en kortere tidslås end den oprindelige (for at sikre, at de kan bruge deres tidligere end tidligere ejere). Denne proces gentages for hver overførsel, indtil tidslåsen ikke længere kan forkortes, hvorefter tilstandskæden skal lukkes ud på kæden.
Owners transfer the entire historical chain of past states with each transfer so that users can verify timelocks have been properly decremented and the operator timestamps them using Grundpille, a variant of Opentimestamps where each piece of data has its own unique “slot” in the merkle tree to guarantee that only a single version of the data is timestamped. This let’s everyone audit the transfer history of a statechain.
I De Blindes Land
Den store forandring, Mercury Layer bringer til den originale version af statechains, er blændende. Operatøren af statechain-tjenesten vil ikke længere være i stand til at lære noget om, hvad der overføres: dvs. de involverede TXID'er, de involverede offentlige nøgler, selv de signaturer, som den samarbejder med brugere om at skabe for de forudsignerede transaktioner, der er nødvendige for at kræve tilbagebetaling dine midler ensidigt.
Ved at introducere en blindet variant af Schnorr MuSig2 kan Mercury lette processen med backout-transaktionssignering uden at lære nogen af detaljerne om, hvad de signerer. Dette nødvendiggør nogle designændringer for at tage højde for det faktum, at operatøren ikke længere kan se og offentliggøre hele en statechains overførselshistorie. De er slet ikke i stand til at validere den transaktion, de underskriver.
I den tidligere iteration blev det unikke ved et nuværende statechain-ejer/transaktionssæt attesteret af operatøren gennem udgivelsen af hele overførselshistorikken for statechainen med Mainstay. Det er ikke muligt her, da operatøren i den blindede version slet ikke lærer nogen detaljer om disse transaktioner. Dette nødvendiggør en ny måde, hvorpå operatøren attesterer det nuværende ejerskab af statskæden. Alle disse data skubbes helt til en valideringsmodel på klientsiden. Operatøren holder simpelthen styr på antallet af gange, den har underskrevet noget for en enkelt statskæde, og fortæller en bruger det nummer, når det bliver anmodet om det. Brugeren modtager derefter transaktionerne fra tidligere statechain-tilstande fra brugeren, der sender til dem, og verificerer helt på klientsiden, at antallet af transaktioner stemmer overens med det, operatøren hævdede, og verificerer derefter fuldt ud, at signaturerne alle er gyldige, og at tidslåsene dekrementeres med det passende beløb hver gang. I stedet for at offentliggøre de fulde statechain-transaktioner og overførselsordre til Mainstay, fordi den er designet til at være uvidende om alle disse oplysninger, offentliggør den sin andel af den offentlige nøgle (ikke den fulde samlede offentlige nøgle) for den aktuelle bruger for hver statechain bruger. Dette giver enhver bruger, der modtager en tilstandskæde, mulighed for at verificere overførselshistorikken og den aktuelle tilstand er legitim i forhold til transaktionsdataene sendt af afsenderen.
Operatørserveren holder styr på unikke tilstandskæder for at tælle tidligere signaturer ved at tildele hver tilstandskæde en tilfældig identifikator ved oprettelsen, gemt med dens pålydende og dens private nøgle og offentlige nøgleandele (ikke hele den samlede offentlige nøgle). Den nye koordineringsordning for sharding og re-sharding af nøglen er udført på en måde, hvor serveren videregiver sin del af nøglen til brugeren, og de nødvendige data til en resharding blindes, så serveren er ude af stand til nogensinde at lære brugerens fulde offentlig nøgleandel, så den kan skabe den fulde samlede offentlige nøgle og identificere mønten i kæden.
Designet giver ikke engang mulighed for, at operatøren kan vide, hvornår den har underskrevet en kooperativ lukning med den nuværende ejer i stedet for en på forhånd underskrevet transaktion for en ny ejer uden for kæden; den ser ingen detaljer til at skelne de to sager fra hinanden. Dette er dog sikkert for brugere, der kan blive angrebet af nogen, der forsøger at "dobbeltbruge" en statskæde uden for kæden, hvilket giver en falsk transaktion, der ikke kunne afgøres. For det første vil denne bruger se på kæden, at UTXO'en, der understøtter denne statechain, var brugt. For det andet ville transaktionshistorikken, fordi operatøren skal underskrive alle statsopdateringer, kun have en klar samarbejdsafslutning i kæden af tidligere transaktioner. Begge disse ting ville give brugeren mulighed for at afvise transaktionen vel vidende, at den ikke var legitim.
Statechains also allow Lightning channels to be “put on top” of the statechain by having the statechain pay out to a multisig address between two people, and the two of them negotiating a conventional set of Lightning commitment transactions on top of it. It would need to close the statechain on-chain before closing the Lightning channel so would need to use longer timelock lengths for Lightning payments, but otherwise would function perfectly normally.
Overall with the massive privacy improvements of the new iteration of statechains, and the composability with Lightning, this opens many doors for the economic viability and flexibility of second layer transactional mechanisms on Bitcoin. Especially in light of the recent radical changes in mempool dynamics and the resulting fee pressure.
Det giver den samme type likviditetsfordele som Ark, dvs. at den frit kan overføres uden at skulle modtage likviditet, men i modsætning til Ark er den levende og funktionel i dag. Det er unægtelig en anden tillidsmodel end noget som Lightning alene, men for de massive gevinster i fleksibilitet og skalerbarhed er det bestemt en mulighed at udforske.
Oprindelig kilde: Bitcoin magasin