By Bitcoin Tidskrift - 4 månader sedan - Läsningstid: 5 minuter
Mercury Layer: En massiv förbättring av statskedjor
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 här.. 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:
Statskedjor är i huvudsak analoga med betalningskanaler på många sätt, det vill säga de är en gemensamt delad UTXO med en försignerad transaktion som en sista utvägsmekanism för människor att upprätthålla sitt ägande. Den största skillnaden mellan en Lightning-kanal och en tillståndskedja är parterna som är involverade i att gemensamt dela UTXO, och hur äganderätten till ett verkställbart krav mot det överförs till andra parter.
Till skillnad från en Lightning-kanal, som skapas och delas mellan två statiska deltagare, öppnas en tillståndskedja med en facilitator/operatör och kan fritt överföras i sin helhet mellan två valfria deltagare som är villiga att lita på operatören för att vara ärlig, helt avstängd -kedja. Någon som vill ladda en tillståndskedja samarbetar med operatören för att skapa en enda offentlig nyckel som både skaparen och operatören har en del av motsvarande privata nyckel, utan att någon av dem har en fullständig kopia av nyckeln. Härifrån förundertecknar de en transaktion som tillåter skaparen att ensidigt kräva tillbaka sina mynt efter ett tidslås.
För att överföra en tillståndskedja samarbetar den nuvarande ägaren med mottagaren och operatören för att signera ett kryptografiskt bevis med sin nyckeldelning på att de överför myntet, och sedan genererar mottagaren och operatören ett nytt par nyckeldelningar som summerar till samma privata nyckel och tecken en tidslåst transaktion för den nya ägaren med ett kortare tidslås än originalet (för att säkerställa att de kan använda sina tidigare än tidigare ägare). Denna process upprepas för varje överföring tills tidslåset inte kan förkortas längre, vid vilken tidpunkt tillståndskedjan måste stängas ut på kedjan.
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 stöttepelare, 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 blindas land
Den stora förändringen som Mercury Layer medför för den ursprungliga versionen av statechains är förblindande. Operatören av tillståndskedjetjänsten kommer inte längre att kunna lära sig något om vad som överförs: d.v.s. de inblandade TXID:erna, de inblandade offentliga nycklarna, till och med signaturerna som den samarbetar med användare för att skapa för de försignerade transaktionerna som krävs för att kräva tillbaka dina pengar ensidigt.
Genom att introducera en förblindad variant av Schnorr MuSig2 kan Mercury underlätta processen för backout-transaktionssignering utan att lära sig någon av detaljerna om vad de signerar. Detta kräver vissa designändringar för att ta hänsyn till det faktum att operatören inte längre kan se och publicera hela en delstatskedjas överföringshistorik. De är inte ens kapabla att validera transaktionen de undertecknar alls.
I den tidigare iterationen intygades unikheten hos en aktuell tillståndskedjeägare/transaktionsuppsättning av operatören genom publiceringen av hela överföringshistoriken för tillståndskedjan med Mainstay. Det är inte möjligt här, eftersom operatören i den blindade versionen inte lär sig några detaljer alls om dessa transaktioner. Detta kräver ett nytt sätt för operatören att intyga det nuvarande ägandet av statskedjan. All denna data skjuts helt till en valideringsmodell på klientsidan. Operatören håller helt enkelt reda på hur många gånger den har signerat något för en enskild tillståndskedja och berättar för en användare det numret när det efterfrågas. Användaren tar sedan emot transaktionerna från tidigare statechain-tillstånd från användaren som skickar till dem, och verifierar helt och hållet på klientsidan att antalet transaktioner matchar vad operatören hävdade, och verifierar sedan fullständigt att alla signaturer är giltiga och att tidslåsen minskas med lämpligt belopp varje gång. Istället för att publicera de fullständiga statechain-transaktionerna och överföringsordern till Mainstay, eftersom den är utformad för att vara omedveten om all denna information, publicerar den sin andel av den publika nyckeln (inte den fullständiga aggregerade publika nyckeln) för den aktuella användaren för varje statechain användare. Detta tillåter alla användare som tar emot en tillståndskedja att verifiera överföringshistoriken och det aktuella tillståndet är legitimt mot transaktionsdata som skickats av avsändaren.
Operatörsservern håller reda på unika tillståndskedjor för att räkna tidigare signaturer genom att tilldela varje tillståndskedja en slumpmässig identifierare vid skapandet, lagrad med dess valör och dess privata nyckel och publika nyckelandelar (inte hela den samlade publika nyckeln). Det nya koordinationsschemat för att skära och dela om nyckeln görs på ett sätt där servern skickar sin del av nyckeln till användaren, och de data som krävs för en omskärning förblindas så att servern inte kan lära sig användarens fullständiga public key share, vilket gör att den kan skapa den fullständiga aggregerade publika nyckeln och identifiera myntet i kedjan.
Designen tillåter inte ens operatören att veta när den har undertecknat en kooperativ stängning med den nuvarande ägaren snarare än en förundertecknad transaktion för en ny ägare utanför kedjan; den ser inga detaljer för att skilja de två fallen från varandra. Detta är dock säkert för användare som kan attackeras av någon som försöker "dubbla spendera" en delstatskedja utanför kedjan och tillhandahåller en falsk transaktion som inte kunde lösas. För det första skulle den användaren se på kedjan att UTXO-stödet för den tillståndskedjan förbrukades. För det andra skulle transaktionshistoriken, eftersom operatören måste underteckna alla statliga uppdateringar, bara ha en tydlig kooperativ stängning i kedjan av tidigare transaktioner. Båda dessa saker skulle tillåta användaren att vägra transaktionen med vetskap om att den inte 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 erbjuder samma typ av likviditetsfördelar som Ark, det vill säga att kunna överföras fritt utan att behöva ta emot likviditet, men till skillnad från Ark är den levande och funktionell idag. Det är onekligen en annan förtroendemodell än enbart Lightning, men för de enorma vinsterna i flexibilitet och skalbarhet är det definitivt en möjlighet att utforska.
Ursprunglig källa: Bitcoin magazine