Kihagyás

Shielded Bitcoin: privát átutalások a Bitcoin L1-en

Tanulmány: Shielded Bitcoin: Private Transfers on the Bitcoin L1 Szerzők: Clara Shikhelman, Mikhail Komarov, Aleksei Moskvin ([[alloc] init], allocinit.xyz) Intézmények: [[alloc] init] Dátum: 2026-09-24 Oldalak: 55 (fő szöveg 22 szekció + A-D függelék + irodalomjegyzék) Forrás: https://www.allocinit.xyz/uploads/shielded-bitcoin.pdf Kinyerés: pdftotext (29 358 szó; a PDF szöveges réteggel rendelkezik) Téma: Shielded-note metaprotokoll Bitcoin L1-en, konszenzusváltoztatás nélkül Alkalmazhatóság a saját rendszerünkre: KÖZEPES (lásd a dedikált szekciót)

Bevezetés és a lényeg

A Bitcoin tranzakciós gráfja véglegesen nyilvános. Az álneves címek ellenére a gráfelemzés, a címklaszterezés és a lánc-metaadatok együtt gyakran kikövetkeztetik a tulajdonviszonyokat. A meglévő megoldások a probléma egy-egy szeletét kezelik: a CoinJoin és a PayJoin a heurisztikákat teszi megbízhatatlanabbá, a Silent Payments az címismétlést kerüli, a nagyobb kifejezőerejű konstrukciók viszont konszenzusváltoztatást igényelnek. Az összegek és a tranzakciószerkezet mindeközben nyilvános marad.

A Shielded Bitcoin egy shielded-note átutalási metaprotokoll, amelynek burkológép-adatát (envelope) a Bitcoin L1-en lehet publikálni ma, konszenzusváltoztatás nélkül. A szerzők három kutató a [[alloc] init] cégtől, a tanulmány 2026. szeptember 24-én jelent meg.

A design a Zcash és a korábbi shielded-note rendszerek architektúrájából kölcsönöz: az érték titkosított note-okban van, a költést nyilvános nullifier-ök jelölik, az érvényességet nulla-tudású bizonyítások igazolják. A Zcash-től egy szerkezeti ponton tér el: nem vezet be saját blokkláncot és saját konszenzust. Minden protokoll-adat a Bitcoinon jelenik meg, az átutalás érvényességét a PIPEs v2 mechanizmus kényszeríti ki, a shielded állapot pedig az elfogadott átutalások determinisztikus újrajátszásával (replay) áll elő, Bitcoin-sorrendben.

A legfontosabb állítások:

  • Nincs konszenzusváltozás. Sem soft fork, sem új lánc, sem külön konszenzus. A Bitcoin csak publikációs és sorrendezési réteg.
  • Az állapot újrajátszásból származik. Két helyes implementáció, ugyanazon a Bitcoin-előtagon futva, koordináció nélkül ugyanahhoz a shielded állapothoz jut. Ezért nincs szükség kihívásra, vitarendezésre vagy optimista visszaállításra.
  • A nullifier a replay által kiosztott pozícióhoz kötődik. Ez az egyik legfontosabb technikai döntés: a Zerocash eredeti konstrukciójában a serial number a fogadó kulcsából és a küldő által választott randomitásból állt, ezért randomitás-újrahasználatnál ütközött. Itt a pozíciót a replay osztja ki, ezért két különböző note-nak akkor is különbözik a nullifier-származtatási bemenete, ha a küldő újrahasználja a note-seedet.
  • A költési jogosultság a felhasználónál marad. A metaprotokoll szintjén az átutalás nem kasztodiális: az indexerek és a replay réteg olvasási jogot kapnak, költési jogot nem.
  • A h_body a teljes testre ható kötés. Enélkül bármelyik nem korlátozott envelope-mezőt át lehetne írni a bizonyítás után. A bizonyítás bájtjai kimaradnak a hashelt részből, mert azok a h_body-ból keletkeznek.
  • Az adatvédelem mérési kérdés, nem állítás. A szerzők explicit szivárgási függvényt (Leak) definiálnak, és a fő adatvédelmi tétel ehhez képest fogalmaz. A nominális privacy-halmaz és a tényleges, entrópia-alapú halmaz nem ugyanaz.
  • A be- és kilépés nincs benne. A peg-in és a peg-out külön komponens, külön bizalmi és élősségi feltételekkel, és a tanulmány szándékosan nem állítja róluk, hogy trustless, privát vagy cenzúra-ellenálló.
  • Egy konkrét implementációs profil rögzített, hogy a független implementációk interoperáljanak: Groth16 bizonyítás, egy OP_RETURN hordozó, 2 bemenet 2 kimenet esetén 610 bájtos envelope, W = 100 és K_min = 1 anchor-ablak. A profil bármely elemén eltérő implementáció nem ugyanazon a hálózaton működik.

Összegzés

A tanulmány egy olyan shield-ed note metaprotokollt ír le, amely a Bitcoint kizárólag publikációs és sorrendezési rétegként használja, a shielded állapotot pedig az elfogadott envelope-ok determinisztikus újrajátszásából származtatja. Az architektúra három felelősséget választ szét: a Bitcoin rögzíti a bájtokat és azok sorrendjét, az indexerek újrajátsszák és szolgálják ki az állapotot, a tárcák építik az envelope-okat és fogyasztják az állapotot. Ez a szétválasztás az, ami a Zcash-szerű shielded konstrukciót konszenzusváltoztatás nélkül teszi lehetővé.

A technikai mag két döntés körül forog. Az első a ciphertext-származtatott note-leaf: a levél nem a privát plaintextből, hanem a publikált h_body, kimeneti index, pk_eph és ct_note mezőkből áll elő, így a titkosított szöveg lesz a híd a privát plaintext, az újrajátszott állapot és a későbbi költés között. A második a replay által kiosztott pozíció bevonása a nullifier-származtatásba, ami a Zerocash serial-number újrahasználati hibáját zárja ki.

A biztonsági elemzés formális: nyolc cél, öt lemma és egy összegzett korlát, amely a Bitcoin közös-előtag feltevéséből, a hash-ütközésből, a bizonyítási rendszer tudás-tömörségéből és az AEAD-ból áll össze. Az adatvédelmi elemzés ugyanilyen fegyelmezett: a szerzők előbb definiálják a szivárgási függvényt, majd játékok sorozatával mutatják meg, hogy a publikált tranzkriptum csak a Leak-en keresztül függ a privát történettől.

A legfontosabb fenntartások: a rendszer nincs telepítve, a tanulmány specifikáció és elemzés, nem működő hálózat. A be- és kilépési mechanizmus (PIPEs v2 alapú peg) külön tanulmány tárgya, és a PIPEs mögötti witness encryption a szerzők saját nyilatkozata szerint is kísérleti. A nominális privacy-halmaz mérete nem garantálja a tényleges adatvédelmet: a tanulmány maga idézi a Zcash empirikus elemzését, ahol a nagy pool ellenére szűk maradt a tényleges halmaz.

A probléma és a pozicionálás

A szerzők a bevezetőben leszögezik, hogy a Bitcoin tranzakciós gráfja véglegesen nyilvános, és hogy az álneves címek ellenére a gráfelemzés, a címklaszterezés és a kiegészítő metaadatok együtt gyakran kikövetkeztetik a tulajdonviszonyokat. Ez a kiindulópont, nem mellékes megjegyzés: a tanulmány egésze erre a tényre épül.

A kapcsolódó munkák négy csoportra bomlanak, és a szerzők mindegyiknél megmondják, hol a határ.

Adatvédelem a Bitcoin UTXO-modellen belül. A CoinJoin, a PayJoin, a címrotáció és a Silent Payments javítják az adatvédelmet, de nem változtatják meg azt a tényt, hogy a Bitcoin tranzakciók átlátszóak. Az összegek, az időzítés, a díjak, a bemeneti és kimeneti szerkezet és a gráf nagy része látható marad. Ezek a technikák a klaszterezést nehezítik, de nem adnak shielded átutalási modellt, ahol a küldő, a fogadó, az összeg és a note-plaintext egy közös titkosított állapoton belül titkos marad.

Saját konszenzussal rendelkező shielded kriptovaluták. A Zerocoin úttörő volt a mint és spend műveleteknél, a Zerocash általánosította nulla-tudású bizonyításokra, a Zcash Sapling és Orchard protokollcsaládja pedig ezt telepítette. A Monero más úton jár: ring aláírások, stealth címek és confidential transaction technikák kombinációja. A szerzők mindkettőnél ugyanazt a megkülönböztetést teszik: ezek saját láncuk natív konszenzusszabályaival kényszerítik ki az érvényességet, a Shielded Bitcoin viszont változatlanul hagyja a Bitcoin konszenzusát, és az állapotot a Bitcoinon publikált envelope-okból származtatja. Az Aztec a programozható adatvédelem irányába visz tovább, ami fontos, de a privát átutalásokhoz képest lényegesen összetettebb.

Bitcoinhoz horgonyzott overlay-ek kliensoldali adattal. A legközelebbi rokon a Shielded CSV, amely szintén soft fork nélküli privát Bitcoin-átutalást céloz, és a proof-carrying data hagyományára épül. A szerzők itt fontos különbséget tesznek: a Shielded CSV jelenleg elméleti protokolljavaslat, nem telepített rendszer, és a Bitcoin-denominált érték használatához hídmechanizmusra (BitVM-stílusú konstrukciókra) támaszkodik. A döntő trade-off viszont az adatelérhetőségi modell: a Shielded CSV nem publikál minden információt, ami a privát rendszerállapot Bitcoin-történelemből való rekonstrukciójához kell, hanem az érmetulajdonosnak kell megtartania a kliensoldali állapotot és bizonyítási adatot. Ha ez a helyi állapot elveszik, a privát tranzakciótörténet a nyilvános láncból általában nem állítható helyre. Az RGB és a Taproot Assets ugyanebbe a családba tartozik: a Bitcoin publikációs, sorrendezési vagy elköteleződési réteg, az eszköz-specifikus jelentést pedig a konszenzuson kívül értelmezik.

Hídolt végrehajtási környezetek. A föderált sidechainek, az EVM-kompatibilis hálózatok és a BitVM-stílusú mechanizmusok lényegesen gazdagabb szemantikát tudnak támogatni, de a Bitcoinhoz való kapcsolatukat a híd közvetíti, ezért öröklik a híd letétkezelési, bizalmi és élősségi feltevéseit. A Shielded Bitcoin szerzői szerint ez nem ugyanaz a viszony, mint amikor a felsőbb réteg állapota a Bitcoin saját publikációs és sorrendezési tulajdonságaiból folyamatosan származik.

A pozicionálás lényege egy mondatban: a determinisztikus újrajátszás a kanonikus Bitcoin-történelem fölött az, ami az egészet lehetővé teszi. Minden helyes implementáció ugyanazt a shielded állapotot rekonstruálja ugyanazokból a publikált átutalásokból, ezért eltérő privát állapotok nem keletkezhetnek, és az átutalási rétegnek nem kell saját kihívás-válasz vagy visszaállítási mechanizmus.

Architektúra: publikáció, újrajátszás, tárca

A rendszer három felelősséget választ szét élesen. A Bitcoin rögzíti minden envelope bájtjait és azok helyét a láncon, de shielded állapotátmenetet nem validál. Az indexerek figyelik a Bitcoin láncot a Shielded Bitcoin átutalásokért, Bitcoin-blokksorrendben újrajátsszák az elfogadott envelope-okat, és fenntartják a note-fát, a nullifier-halmazt és a blokk-szintű gyökér-történetet. A tárcák ezt az újrajátszott állapotot fogyasztják: felismerik a bejövő note-okat, Merkle-tanúkat szereznek, és költéseket építenek.

Az indexerek nem letétkezelők, és nem rendelkeznek költési jogosultsággal. Az állapotot rekonstruálják és kiszolgálják, de a tárca az állapotot a Bitcoinon publikált adatokból függetlenül is ellenőrizheti. Egy tisztességtelen indexer cenzúrázhat envelope-okat vagy tetszőleges gyökeret jelenthet, de nem tudja azt a gyökeret konzisztenssé tenni ugyanazon Bitcoin-történelem független újrajátszásával.

A shielded állapot formális definíciója az 1. definíció: bármely replay-határon a metaprotokoll-állapot az S := (T, N, R, H) négyes, ahol T az csak-hozzáfűző note-leaf Merkle-fa, N az elfogadott nullifier-ök halmaza, R a megtartott blokk-magasság térkép R[h], H pedig az elfogadott átutalás-történet replay-sorrendben.

A replay viselkedése pontosan rögzített. Minden elfogadott átutalásnál származtatja az ℓ értékeket a nyilvános kimeneti adatokból, hozzáfűzi a leveleket a T-hez, és beilleszti a publikált nullifier-öket az N-be. Egy átutalás érvénytelen, ha ugyanazt a nullifier-t kétszer tartalmazza, vagy ha bármelyik nullifier-e már szerepel az N-ben. Az érvénytelen envelope-ok nem módosítják az újrajátszott állapotot. A gyökereket nem minden elfogadott átutalás után rögzítik: minden H blokkra az indexer a H-1 utáni gyökérből indul, kanonikus sorrendben feldolgozza a tranzakciókat, és a keletkező gyökeret csak a teljes blokk újrajátszása után tárolja R[H] néven. Ha a blokk nem tartalmaz elfogadott átutalást, R[H] = R[H-1], tehát minden megtartott magasságnak van jól definiált gyökere.

Az envelope nem publikálja a teljes anchor-gyökeret, hanem csak a h_anchor blokkmagasságot. Az indexer a replay során lokálisan rekonstruálja a megfelelő gyökeret r_anchor := R[h_anchor] formában. Ez a h_anchor tehát egy tömör hivatkozás egy blokk-szintű replay-ellenőrzőpontra, nem shielded-átutalás sorszám és nem az elfogadott protokoll-események számlálója.

Az anchor-ablak. A protokoll-szintű érvényes anchor-ablakot egy maximum és egy minimum mélység definiálja: H - W ≤ h_anchor ≤ H - K_min, ahol H az éppen újrajátszott Bitcoin-blokk, W a maximális anchor-életkor, K_min pedig a protokoll által megkövetelt minimális anchor-mélység. Mindkettő Bitcoin-blokkban mért érték.

Itt a szerzők egy fontos figyelmeztetést tesznek: W értéke replay-szabály, nem telepítési konfiguráció. W különböző elfogadott értékei különböző érvényességi predikátumot adnak az indexereknek, és minden olyan láncra, amely tartalmaz egy predikátum által elfogadott, a másik által elutasított átutalást, a replay eltérő shielded állapotot származtat. A K_min a legkisebb mélység, amellyel az anchor-gyökér már definiált az aktuális blokk feldolgozása előtt; a legkisebb természetes választás K_min = 1, ami megengedi R[H-1]-et, de tiltja R[H]-t, és ezzel azt is megakadályozza, hogy egy H blokkban létrehozott note-ot ugyanabban a blokkban elköltsenek.

A tárca ezen felül szigorúbb helyi politikát alkalmazhat: K_wallet ≥ K_min. Ez a határ nem protokoll-szabály, hanem annak kifejezése, mennyi bizonyosságot akar a tárca arról, hogy a bizonyításhoz használt gyökér az aktív láncon marad. Az átszervezési biztonság külön tárca-politikai kérdés, mert ha a tárca R[H-1] ellen építi a bizonyítást, egy egyblokkos átszervezés kicserélheti a H-1 magasságú blokkot, megváltoztathatja az ottani gyökeret, és a bizonyítás érvénytelenné válik az új aktív láncon. A bizonyítás ilyenkor nem hibás: olyan állapotra készült, amely már nem az aktív lánc újrajátszásából adódó állapot.

A maximális életkor más célt szolgál: megadja, meddig marad elfogadható egy kiválasztott anchor a bizonyítás elkészítése után. Ha W túl kicsi, a tárcának kevés ideje marad a publikálásra, ami érzékennyé teszi a díjkésésekre, az offline aláírásra, a lassú koordinációra és a relayer-munkafolyamatokra. A W növelése közvetlen kockázatot nem hoz, mert a replay az aktuális N ellen ellenőrzi az összes publikált nullifier-t az anchor korától függetlenül. A költségek operatívak: hosszabb gyökér-történetet kell megtartani, és a szokatlan anchor-életkorok ujjalenyomatként működhetnek. Ha a legtöbb tárca 6 és 20 blokk közötti mélységű anchor-t használ, és egy átutalás 700 blokkosat, az offline aláírást, relayer-késést vagy nem szabványos tárca-politikát sugallhat.

Note-modell, kulcshierarchia és címek

A shielded tulajdon alapegysége a note, amely szerepében a Bitcoin UTXO-hoz hasonlít: diszkrét értékdarab, amelyet a tulajdonosa később elkölthet. A különbség az, hogy a note a nyilvános láncon titkosítással és kapcsolódó nyilvános protokoll-adattal jelenik meg, nem a plaintext tartalmával.

A note plaintext meglepően kicsi, és a szerzők ezt tudatos tervezési döntésként mutatják be:

pt_note := (v, d, r_seed)

Itt v a kanonikus előjel nélküli satoshi összeg, d a diverzifikált fogadási útvonalat azonosítja, r_seed pedig friss, note-specifikus randomitás. A többi note-szintű értéket nem tárolják plaintext mezőként, hanem determinisztikusan származtatják a seedből:

ρ := H_ρ(r_seed)
sk_eph := ScalarFromBytes(H_eph(r_seed))
pk_eph := [sk_eph] G_d

A ρ a nullifier-származtatás note-specifikus bemenete, a sk_eph a note efemer titkos kulcsa a kimeneti titkosításhoz, a pk_eph pedig a hozzá tartozó publikált efemer kulcs. A fogadónak csak a (v, d, r_seed) hármast kell visszafejtenie a fogadói ciphertextből. Utána a tárca újraszármaztatja ρ-t, sk_eph-et és pk_eph-et, ellenőrzi, hogy a származtatott pk_eph megegyezik az elfogadott envelope-ban publikálttal, majd ellenőrzi, hogy a hozzá tartozó ℓ az, amit a replay kiosztott. Mivel a note a Bitcoinra titkosított ciphertextként kerül, a kisebb plaintext közvetlenül csökkenti a kimenetenkénti láncköltséget.

A note-levél egy h_aux mezőt is hordoz, amely nem része a titkosított note-plaintextnek, és nem kerül bele a ct_note-ba. A küldő adja meg a note létrehozásakor, és a nyilvános levél-származtatásba kerül be. A h_aux jelenleg a aux_null kanonikus konstansra van rögzítve és nem szerializálódik, de fenntartott bővítési hely: a tervezett felhasználás egy atomi swap hash-lockjának elkötelezése a note létrehozásakor, anélkül hogy a kiegészítő adat a note-plaintextbe kerülne.

Egy note három állapot egyikében van: létrehozott, ha a levele bekerült a fátba a replay által; elkötött, ha a nullifier-e publikálva és elfogadva lett; vagy megerősítetlen, ha csak egy el nem fogadott vagy még újra nem játszott envelope-ban szerepel. Egy note addig nem költhető, amíg nincs megerősített pozíciója a note-fában.

Kulcshierarchia. A kulcsmodell a költési jogosultságot, a bejövő megtekintést és a kimenő helyreállítást külön tárca-képességekre bontja, egyetlen seedből, rögzített, domain-szeparált HKDF-SHA256 címkékkel. A táblázat szerinti származtatási lánc:

  • sk_master = HKDF_master(seed_wallet)
  • sk_spend = ScalarFromBytes(HKDF_spend(sk_master))
  • sk_nf = HKDF_nf(ser(sk_spend))
  • vk_in = HKDF_in(ser(sk_spend))
  • vk_out = HKDF_out(sk_master)

A szerkezeti lényeg a szülőviszonyokban van. A sk_nf a ser(sk_spend) gyermeke, ezért a nullifier-származtatás a költési jogosultsághoz kötve marad. A vk_in szintén a ser(sk_spend) gyermeke, de csak olvasható: a vk_in felfedése a bejövő note-okat mutathatja meg, költést nem engedélyez. A vk_out a sk_master-nél válik szét, és a kimenő történetet tárhatja fel, de nem ad sk_spend-et vagy sk_nf-et.

Egy fogadási útvonalhoz a tárca egy d diverzifikálót választ:

sk_view := ScalarFromBytes(HKDF_view(vk_in))
G_d := DiversifyHash(d)
pk_d := [sk_view] G_d
addr_d := (d, pk_d)

A fizetési cím nyilvános, és kizárólag az egyenlet objektumaiból áll. A küldő a pk_d-t használja a fogadói Diffie-Hellman számításban, és a d-t helyezi a titkosított note-plaintextbe. A visszafejtés után a fogadó a d alapján azonosítja a helyi fogadási útvonalat, és újraszármaztatja a pk_d-t a vk_in-ből. A diverzifikáló tehát az cím-névtér része, nem önálló költési jogosultság-forrás.

Felfedési és auditmodell. A felfedés tárca-vezérelt, csak olvasható művelet. Sem konszenzusszabály, sem protokoll-hátsóajtó, sem alternatív költési útvonal. Nincs globális felfedési kulcs, és a felfedési képességek nem ruháznak át letétkezelést vagy költési jogosultságot az auditornak vagy bármely protokoll-szolgáltatónak. A szerzők négy felfedési módot definiálnak:

  • IncomingView: a vk_in megosztása, ha az auditornak önállóan meg kell találnia a tárca által fogadott kimeneteket az elfogadott történelemben. Hasznos bevétel-ellenőrzéshez és a fogadott note-plaintextek helyreállításához. Csak olvasható, nem ad hozzáférést a kimenő helyreállítási rekordokhoz, nem azonosítja, mely note-okat választották bemenetként, és nem ad költési jogosultságot.
  • OutgoingView: a vk_out megosztása a küldő oldali rekordok vizsgálatához. Költség-átvizsgáláshoz, partneri egyeztetéshez és a ct_out-ból származó küldési előzmények bizonyításához hasznos. Nem azonosítja azokat a bemeneti note-okat, amelyeket ezek az átutalások felemésztettek.
  • NoteOpening: egy konkrét note, kimenet, átutalás vagy riportbejegyzés megnyitása, ha az audit helyi. Az auditor a megnyitott plaintextet az elfogadott envelope-hoz, az újrajátszott note-levélhez, a Merkle-úthoz és az igényelt pozícióhoz ellenőrzi.
  • DerivedReport: riport exportja, ha az auditornak csak egy korlátos állítás kell, például időszaki beáramlás, kiáramlás, partneri összesítés, note-tulajdon vagy egyenleg egy H magasságon.

A szerzők figyelmeztetnek, hogy a nyers vk_in és vk_out széles olvasási képesség. A Q hatókör korlátozza az audit-állítást, de kriptográfiailag nem korlátozza a nyers viewing kulcsot: aki vk_in-t vagy vk_out-ot kap, bármely elérhető replay-történelemre alkalmazhatja. Ha az auditornak nem szabad megismernie a nem kapcsolódó egyező történelmet, a tárcának note-megnyitást vagy származtatott riportot kell használnia. És ami a legfontosabb: egyetlen felfedési anyag sem tartalmaz seed_wallet-et, sk_spend-et vagy sk_nf-et, mert a sk_nf kizárása azt is megakadályozza, hogy a felfedés általános nullifier-összekapcsoló eszközzé váljon.

A protokoll: levél, nullifier, envelope és kötés

Note-levél és nullifier. A replay minden létrehozott kimenethez egy kanonikus note-fa levelet származtat a nyilvános envelope-adatokból:

ℓ_j := H_leaf(const_salt, h_body, j, pk_eph,j, ct_note,j, h_aux,j)

A j a zéró-alapú kimeneti index az aktuális envelope-on belül, nem a globális Merkle-pozíció. A globális pos-t a replay osztja ki később, amikor az elfogadott note-leveleket Bitcoin-sorrendben hozzáfűzi a fához. Későbbi költéshez a tárca mindkét azonosítót tárolja: a létrehozási kimeneti indexet, ami újraszármaztatja a note-levelet, és a kiosztott fa-pozíciót, amit a Merkle-út és a nullifier-reláció használ.

A költött note-okra a nyilvános spend-marker reláció:

nf := H_nf(BytesToField(sk_nf), BytesToField(ρ), pos)

Itt sk_nf a nullifier-származtatást a költő által ellenőrzött titkos anyaghoz köti, ρ a nullifier-t note-specifikussá teszi, a pos pedig a költést a note-levél globális fában elfoglalt kiosztott pozíciójához. Újrajátszott metaprotokollban ez a pozíció a költési identitás része.

A szerzők itt egy kulcsfontosságú megkötést tesznek: a sk_nf nem önálló witness-titok. Az áramkör determinisztikusan származtatja a sk_spend-ből, és elutasítja azt a konstrukciót, amely lehetővé tenné a bizonyítónak, hogy a sk_nf-et külön válassza. Erre a kötésre azért van szükség, hogy egy költési jogosultság egy nullifier-származtatási utat implikáljon egy adott note-hoz és pozícióhoz. Enélkül ugyanazt a note-ot többször lehetne elkölteni különböző nullifier-ökkel.

Az áramkör-szintű tulajdonosi szabály megköveteli, hogy minden költött bemeneti note-ra a sk_spend-ből származtatott diverzifikált fogadási kulcs egyezzen a note ciphertext-relációjában használt pk_d-vel. Ez a szabály csak a bemenetekre vonatkozik: a létrehozott kimenetek a cél fizetési címéről választott fogadói oldali pk_d-re titkosítanak, és nem származtatják azt a küldő sk_spend-jéből.

Az envelope. A logikai envelope szerkezete hét mezőből áll a bizonyítás előtt: header (mágikus bájtok, verzió, átutalás-típus), h_anchor, input_count, output_count, a nullifier-ök vektora, a kimenetenkénti pk_eph vektor, a fogadói ciphertext-ek vektora, a ct_out küldő-helyreállítási ciphertext, végül a π bizonyítás. A bináris sorrend rögzített, és a π a test bájtjai után szerializálódik.

Testkötés. A bizonyítás csak azokat a mezőket korlátozza, amelyek publikus bemenetként az áramkörbe kerülnek. A többi publikált mező nincs egyenként kitéve az ellenőrzőnek: a szerializált header, a h_anchor, az explicit bemeneti és kimeneti darabszám, és a ct_out. Explicit elköteleződés nélkül ezek bármelyike újraírható lenne a bizonyítás után anélkül, hogy a bizonyítás-ellenőrzést befolyásolná. A h_body zárja be ezt a rést, egyetlen objektumként kötelezve el a teljes nyilvános testet:

h_body := H_body(const_salt || canonical_transfer_body)

A π mező kimarad a hashelt bájtokból, mert a h_body-ból keletkezik és csak a bizonyítás befejezése után fűződik hozzá; a hashelése körkörös lenne. Mivel a hash az egész testet lefedi, a publikált envelope egységként nem malleálható. A kötés a note-fába is elér: minden kimenet ℓ_j-je a h_body, a kimeneti index, a pk_eph,j és a ct_note,j együtteséből keletkezik, ezért ugyanaz a ciphertext egy másik átutalásban vagy más kimeneti pozícióban különböző levelet ad. A replay a kötést minden állapotváltozás előtt ellenőrzi.

Az átutalási állítás. A publikus állítás a bizonyítás és a replay közötti interfész: a származtatott r_anchor, a bemeneti és kimeneti darabszámok, a nullifier-ök, a kimenetenkénti pk_eph és ct_note értékek, valamint a h_body. A h_anchor önmagában nem külön bizonyítási bemenet, hanem a h_body-on keresztül kötődik. A nullifier-egyediséget a replay kényszeríti ki, nem az áramkör.

Az áramkör kilenc feltételt igazol egy átutalásra: minden bemeneti note létezik a kiválasztott r_anchor alatt; a bizonyító ismeri a kanonikus pozíciót és a Merkle-utat; ismeri a költéshez szükséges titkokat; a publikált nullifier-ök pontosan a költött bemeneti note-okból származtatott értékek; a nyilvános pk_eph és ct_note értékek ugyanazokat a kimeneti note-okat titkosítják, amelyeket az áramkör használ; a kimeneti levél-származtatásba kerülő publikus mezők azok, amelyeket a h_body köt és a bizonyítás ellenőriz; minden érték kanonikus satoshi összeg a megengedett tartományban; a bemeneti értékek összege egyenlő a kimenetiek összegével moduláris túlcsordulás nélkül; és a Bitcoinra publikált envelope ugyanaz, amelyre a bizonyítás kötődik.

A witness a privát adatot tartalmazza. Bemenetenként: érték, diverzifikáló, seed, a létrehozási h_body, a létrehozási kimeneti index, a pk_eph, a ct_note, a pozíció és a Merkle-út. Kimenetenként: érték, d, pk_d, seed. Emellett egyetlen sk_spend, ami az összes bemeneti költést engedélyezi. A szerzők kifejezetten kizárják a witnessből az előre kiszámított note-leveleket, nullifier-öket, ρ-t és sk_eph-et: ezeket az áramkörön belül kell származtatni, hogy az áramkörön kívüli segédlogika ne tudjon csendben eltérni az áramkör szemantikájától. A sk_nf szintén nem szabad witness-érték.

Replay és elfogadás. Minden envelope-nak először egy közös validációs rétegen kell átmennie: a bináris payload parse-olható, a mágikus bájtok és a verzió egyeznek, a vektorhosszak megegyeznek a deklarált darabszámokkal, a görbepontok dekódolhatók, és a bizonyítás által kötött h_body egyenlő a kanonikus testből újraszámított értékkel. Utána az indexer ellenőrzi, hogy h_anchor az érvényes ablaksávban van, származtatja r_anchor-t az aktív lánc gyökértérképéből, elutasítja az ismétlődő vagy már jelen lévő nullifier-öket, és ellenőrzi a bizonyítást a származtatott gyökér ellen.

A replay csak azután módosítja a kanonikus állapotot, hogy minden érvényességi feltétel teljesült. Egy elutasított envelope az S-t változatlanul hagyja, soha nem alkalmazódik részlegesen. A 2. definíció ezt formalizálja: az Accept(S, B, e) predikátum hamis értéke esetén az állapotátmenet identitás, igaz értéke esetén a fa, a nullifier-halmaz és a történet a megadott módon frissül.

Átszervezés. A replay az aktív láncon van definiálva, ezért egy Bitcoin-átszervezés megváltoztatja a bemenetét. R[h] megváltozhat az első kicserélt magasságra és minden utána következőre. Egy envelope, amelynek h_anchor-ja a kicserélt láncon lévő gyökérre hivatkozott, csak akkor fogadható el az új aktív láncon, ha a bizonyítása még mindig ellenőrződik az adott magasságra most származtatott gyökér ellen. A mempool soha nem replay-állapot: a tárcák kizárólag az elfogadott blokkok determinisztikus újrajátszásából nyert gyökerek ellen építenek költési bizonyítást.

Biztonsági elemzés

Az elemző rész nyolc célt rögzít (G1-G8): replay-egyezés, kétszeres költés elleni ellenállás, egyensúly, test-állítás kötés, költési jogosultság, tárca-helyreállítás, átutalás tömörsége és tranzkriptum-adatvédelem. Az első hét célt az 1. tétel összegzi egyetlen korlátban:

ε_btc(k) + c_H · Adv_cr_H(λ) + q · c_K · Adv_ks_Rtr(λ) + Adv_aead(λ) + Adv_auth(λ)

ahol ε_btc(k) a Bitcoin közös-előtag feltevésének bukási valószínűsége k mélységen, Adv_cr_H a hash-ütközés előnye, Adv_ks_Rtr a bizonyítási rendszer tudás-tömörségi előnye, q az elfogadott envelope-ok száma, c_H = c_K = 3 a közreműködő lemmákat gyűjti össze, Adv_aead a titkosítás integritás-előnye, Adv_auth pedig a becsületes note ellopásának előnye.

A szerzők megjegyzik, hogy a per-envelope extrakciós faktor q csak a tudás-tömörségi tagot szorozza: az ütközési és AEAD-redukciók feszesek, mert a publikált objektumok közül bármelyik ütköző vagy hamisító példány közvetlenül töri meg az egy-példányos játékot.

Kétszeres költés. Az 1. lemma a Adv_cr_H + q · Adv_ks_Rtr korlátot adja. Az indoklás szerkezeti: minden elfogadott bemenet olyan nullifier-t publikál, amely a note-specifikus ρ-ból, a sk_nf kulcsanyagból és a replay által kiosztott pos-ból származik. A replay elutasítja az ismétlődő nullifier-t egy envelope-on belül és az N_C ellen. A költő nem választja meg a pos-t: azt akkor osztja ki a rendszer, amikor a kimeneti levél bekerül a note-fába, ezért ugyanazon költés újbóli publikálása egy másik h_anchor ellen megőrzi a nullifier-t.

Itt jön a Zerocash-sel való összehasonlítás, ami a tanulmány egyik legérdekesebb megjegyzése. Mivel a nullifier a replay által kiosztott pos-hoz kötődik, a különböző elfogadott note-oknak akkor is különbözik a származtatási bemenetük, ha a küldő újrahasználja az r_seed-et. Ez elkerüli az eredeti Zerocash konstrukcióban azonosított sorozatszám-újrahasználati hibát, ahol a serial number a fogadó kulcsát kombinálta a küldő által választott randomitással, ezért randomitás-újrahasználatnál ütközött.

Tömörség, egyensúly, jogosultság. A 2. lemma q · Adv_ks_Rtr korlátot ad az átutalás tömörségére, az 1. következmény pedig ebből vezeti le az egyensúlyt és a költési jogosultságot. Az érvelés: a replay nem vizsgál titkosított értékeket, csak akkor fogad el egy átutalást, ha a bizonyítás ellenőrződik egy olyan publikus állításra, amelynek witnesse kielégíti az R_tr relációt, ami ellenőrzi a note-tagságot, a Merkle-út konzisztenciáját, a bemeneti tulajdont, a nullifier-származtatást, az értéktartományt és az egészértékű értékmegmaradást. A vk_in és a vk_out csak megtekintési képességek, és az R_tr nem fogadja el őket költési jogosultságként.

A 2. következmény a főkönyv-egyensúlyt és a lopás-ellenállást köti össze, hozzáadva az Adv_auth tagot. A bizonyítás vázlata szerint az egyensúlyi invariáns indukcióval következik az elfogadott belső átutalásokon: minden elfogadott belső lépés eltávolítja a bemeneti értékeket és egyenlő kimeneti értékeket ad hozzá, ezért V_active változatlan marad. A belépés és a kilépés konstrukció szerint kimarad, és saját elszámolást hordoz.

Malleabilitás és a bizonyítás újrandomizálása. A 4. lemma a Adv_cr_H + q · Adv_ks_Rtr korlátot adja az állítás-malleabilitásra. A szerzők külön bekezdést szentelnek annak, amit a lemma nem tilt: a bizonyítás újrandomizálását. Az implementációs profilban rögzített Groth16 megengedi, hogy egy érvényes bizonyításból egy másik, szintén érvényes bizonyítást származzunk ugyanarra a publikus állításra. Mivel a h_body a bizonyítás bájtjai nélkül számítódik, az újrandomizált másolat ugyanazt a testet, ugyanazt a h_body-t és ugyanazokat a nullifier-öket adja. Mivel minden belső átutalás legalább egy nullifier-t publikál, az újrandomizált másolat újrapublikálja azt a nem üres nullifier-vektort, és a replay ismétlődő nullifier-ként elutasítja. Az újrandomizálás tehát nem eredményez kétszeres költést, lopást vagy állapot-divergenciát, de megváltoztatja a hordozó tranzakció azonosítóját, ami a publikációs réteg kérdése.

Helyreállítás. A 3. lemma az Adv_aead + Adv_cr_H korlátot adja. A bejövő helyreállítás az átutalásokat szkenneli és a bejövő viewing képességgel próbál visszafejteni, a kimenő helyreállítás a vk_out-ot, a ct_out-ot és a sorrendezett nyilvános kimeneti adatot használja. Egy jelölt note csak akkor kerül be a tárca-nézetbe, ha a plaintext konzisztens a ciphertexttel, a publikus pk_eph egyenlő [sk_eph]G_d-vel, és a származtatott ℓ a replay által kiosztott levél. A hibás ciphertext-ek, hibás pontkódolások és véletlen visszafejtések ezért csak AEAD-hibán, hash-hibán vagy elérhetetlen történelmen keresztül juthatnak be.

Adatvédelmi modell és a szivárgási határ

A tanulmány adatvédelmi része módszertanilag a legerősebb. A szerzők először tisztázzák, mit nem állítanak: nem állítják, hogy a Shielded Bitcoin minden Bitcoin-szintű metaadatot eltüntet, és nem adnak végpontok közötti adatvédelmi áttekintést a peg-inről, peg-outról, díjfinanszírozásról, tárca-hálózatról vagy relayer-működésről. A cél a bizalmasság és az átutalási relációk adatvédelme, de nem a megfigyelhetetlenség: minden átutalás publikál egy envelope-ot a Bitcoinra, ezért az a tény, hogy egy átutalás megtörtént, az időzítése és az aritása konstrukció szerint megfigyelhető.

A formális definíció szerint a nyilvános tranzkriptum egy explicit szivárgási függvényen túl nem árul el semmit a privát történetről. A Leak(X) szivárgási függvény négy csoportot gyűjt össze:

  • Bitcoin publikációs metaadat: blokkmagasság, tranzakciósorrend, hordozó tranzakció szerkezete, díjak, díjráta-viselkedés, finanszírozó bemenetek, visszajáró kimenetek és bármely Bitcoin-szinten látható tárca-klaszterezési információ.
  • Envelope-alak: protokollverzió, átutalás-típus, h_anchor és ezáltal a gyökér kora H - h_anchor, bemeneti és kimeneti darabszám, envelope-méret.
  • Replay-ütemterv: elfogadás vagy elutasítás a kanonikus újrajátszás szerint, a note-leaf beszúrási sorrendje és a kiosztott fa-pozíciók ordinális indexként, valamint az érvényes ablaksáv magasságai.
  • Határmetaadat: a metaprotokollba belépő vagy onnan kilépő érték által felfedett nyilvános információ. A jelenlegi verzióban ez tartalmazza a belépéskor látható nyilvános Bitcoin-tranzakciót és összeget, mert a peg-in és a peg-out kimarad az átutalási specifikációból.
  • Felfedett képességek: bármely vk_in, vk_out, note-plaintext, riport vagy partneri információ, amelyet a felhasználó átad a támadónak.

A 2. tétel a tranzkriptum-adatvédelmet mondja ki:

Adv_priv(λ) ≤ q · Adv_zk(λ) + (n_o + q) · Adv_enc(λ) + n_i · Adv_prf(λ) + (q_nf · 2^-ℓ_nf) / 2

ahol q az elfogadott envelope-ok, n_o a kimeneti note-ok, n_i a bemeneti note-ok, q_nf a publikált nullifier-ök száma, ℓ_nf pedig a nullifier kimeneti hossza, és az utolsó tag a G_3 játékban végzett egyenletes nullifier-helyettesítés születésnapi korlátja.

A bizonyítás három játékból áll, és érdemes megérteni, mi történik bennük:

  • G1 (bizonyítások): minden átutalási bizonyítást a nulla-tudású szimulátor által gyártott bizonyításra cserélnek a saját publikus állítására. A q · Adv_zk hibát adja. Utána a bizonyítás bájtjai csak a publikus állítás függvényei, witness-információt nem hordoznak.
  • G2 (ciphertext-ek): minden kimenet pk_eph-jét friss efemer kulcsként újramintavételezik, és minden fogadói ciphertextet és a küldő-helyreállítási köteget egy rögzített, egyenlő hosszúságú nulla-plaintext titkosítására cserélik, a mögöttes kulcstól függetlenül. A fogadói és küldői identitás adatvédelme a kulcs-privátságból, a plaintext bizalmassága a szemantikai biztonságból következik.
  • G3 (nullifier-ök): minden publikált nullifier-t megfelelő hosszúságú egyenletes sztringre cserélnek. A sk_nf-en kulcsolt nullifier-származtatás pszeudorandomitása miatt a hibát n_i · Adv_prf adja. A helyettesített sztringek ütközhetnek egymással vagy más publikált nullifier-rel, de csak a születésnapi valószínűséggel, amit a szerzők explicit additív tagként visznek tovább.

A G_3 után minden titokból származtatott publikált objektum olyan értékre cserélődött, amely csak a Leak-en keresztül függ a privát történettől. A szerzők itt egy figyelemre méltó megjegyzést tesznek: a származtatott note-leaf értékek, a blokk-szintű gyökerek és a h_body ezeknek a most világfüggetlen objektumoknak a determinisztikus függvényei a kanonikus újrajátszás mellett, ezért nem fogyasztanak ütközés-ellenállási tagot, mert az érv csak azt igényli, hogy ezek a származtatások determinisztikusak.

Amit egy elfogadott átutalás nem tesz ki. A publikus állítás felfedi a kiválasztott r_anchor-t, a bemeneti és kimeneti darabszámokat, a nullifier-öket, a kimeneti ciphertext-mezőket és a h_body-t. Nem teszi ki a bemeneti note-plaintexteket, a kimeneti note-plaintexteket, a bemeneti Merkle-utakat, a sk_spend-et, a sk_nf-et, a vk_in-t, a vk_out-ot, a fogadói pk_d értékeket, azt, hogy mely nyilvános note-levelek szolgáltak bemenetként, és a felemésztett note-ok és a létrehozott note-ok közötti megfeleltetést.

A megmaradó szivárgási felületek. A szerzők négy elsődleges felületet neveznek meg.

  • Átutalás-aritás. Egy 1-ről 2-re és egy 2-ről 1-re menő átutalás megkülönböztethető, még akkor is, ha mindkettő titkosítja a küldőt, a fogadót és az összeget. Az envelope-alak és a hordozó tranzakció szerkezete ezt nyilvánvalóvá teszi.
  • Anchor-kor. A nullifier felfedi, hogy valamilyen note-költést elfogadtak egy adott Bitcoin-blokkban, de nem azt, hogy melyik korábbi levél lett elkötve. Az anchor-gyökér viszont korlátozást szivárogtat meg: minden bemenetnek már léteznie kellett R[h_anchor] alatt. A H - h_anchor értéke nyilvános, ezért a szokatlan anchor-életkorok ujjlenyomatot adhatnak a tárcákról vagy az aláírási munkafolyamatokról.
  • Envelope-csoportosítás. Mivel minden kimenet egy átutalás h_body-jához kapcsolódik, az egy átutalás minden kimenete ugyanazt a h_body-t hordozza. Két fogadó, aki összehasonlítja a megfigyelt h_body-t, megállapíthatja, hogy együtt fizették ki őket, és ezáltal hogy közös küldőjük van. Azoknak a tárcáknak, amelyeknek ezt el kell kerülniük, a nem összetartozó fizetéseket külön átutalásokra kell bontaniuk.
  • Díjtárca-kapcsoltság. A hordozó tranzakciónak bányászdíjat kell fizetnie. Ha ezeket a hordozó tranzakciókat ismételten ugyanabból az átlátszó Bitcoin tárca-klaszterből finanszírozzák, a Bitcoin szintjén össze lehet kapcsolni őket, még akkor is, ha a shielded átutalás tartalma titkos marad. A szerzők ezt élesen megkülönböztetik: az átutalás adatvédelme és a publikálás adatvédelme két külön dolog.

A szerzők a díj-finanszírozás lehetséges irányaként egy PIPE-alapú díj-tárat vázolnak fel: a felhasználó bizonyítja a jogosultságát egy PIPE-vezérelt díj-tárhoz, amelynek Bitcoin-likviditása az adott felhasználó publikációs költségeire van fenntartva. Amikor a társzabály ellenőrződik, a tár kiadja a hordozó tranzakció finanszírozásához szükséges Bitcoint. A közzétevőnek nem kell megismernie a privát átutalás tartalmát: a felhasználó helyben építi az envelope-ot és a bizonyítást, a közzétevő csak a nyilvános envelope-ot és a díjfeloldási szabályhoz szükséges adatot látja. A szerzők hozzáteszik, hogy a tár-hozzáférési minták, a visszatérítési szerkezet, a publikációs időzítés és a közzétevővel való interakció továbbra is megfigyelhető metaadattá válhat, ezért a díjfeloldási mechanizmusnak saját szivárgási elemzésre van szüksége.

A privacy-halmaz és a tényleges adatvédelem. A szerzők itt a tanulmány legerősebb önkorlátozó szakaszát adják. A privacy-halmaz mindig egy támadóhoz, egy megfigyelési modellhez és egy érdekes titokhoz képest definiált. A Shielded Bitcoinnál a releváns titok nem egy felhasználói identitás elszigetelten: a költési oldalon az a note-levél, amelyet egy nyilvános nullifier felemészt, a kimeneti oldalon pedig a fogadó által ellenőrzött note-plaintext és az azt létrehozó privát történet.

A szerzők figyelmeztetnek, hogy egy nagy globális note-fa csak szintaktikai felső korlátot ad a költési privacy-halmaz méretére. Ez lényegesen túlbecsülheti a felhasználói szintű adatvédelmet, ha kevés szereplő hozta létre a note-ok többségét, ha a támadó sok note-ot ellenőriz vagy ismert meg, vagy ha egy tárca ismételten megkülönböztethető publikációs mintákat használ. A költési oldalon a protokoll-szintű jelölthalmazt az R[a] alatt már elkötelezett note-levelek korlátozzák, de a jelölthalmazt csökkenti minden kiegészítő tudás: a támadó által ellenőrzött levelek, a felfedett plaintexttel vagy viewing adattal rendelkező levelek, a láncon kívüli partneri rekordokból ismert levelek, és a határeseményekkel, időzítéssel, díjviselkedéssel vagy tárca-politikával össze nem egyeztethető levelek.

A kardinalitás önmagában gyenge mérték, ha a jelöltek nem egyformán valószínűek. Az entrópia-alapú privacy-halmaz metrika szerint |A_eff| := 2^H(P), ahol P a támadó posterior eloszlása a jelöltek fölött. Az effektív méret csak egyenletes posterior esetén egyezik a nyers jelöltszámmal. A szerzők maguk idézik a Zcash empirikus elemzését, ahol ez a gyakorlati tanulság már megjelent: a nagy nominális pool önmagában nem implikál nagy effektív privacy-halmazt. A végső állítás ezért feltételes: a Shielded Bitcoin a szivárgási függvénnyel kompatibilis történetek halmazán belül titkosítja az elkötött note-ot és a kimeneti plaintextet, és ennek a halmaznak a mérete és eloszlása telepítési tulajdonság.

Implementációs profil és költségek

Az A függelék egy konkrét implementációs profilt rögzít, hogy a független implementációk interoperáljanak. A szerzők világossá teszik, hogy az átutalási reláció maga nem függ ezektől a választásoktól, viszont az interoperabilitás megköveteli, hogy egy adott hálózaton minden újrajátszó implementáció ugyanazt a csomagot ossza, mert a replay elfogadási predikátuma tartalmazza a kanonikus szerializációt, a test- és aritás-elrendezést, a hordozó-meghatározási szabályt, a bizonyítás-ellenőrzést egy rögzített ellenőrző kulccsal, a W anchor-szabályt a hálózat-szintű K_min minimummal, és a determinisztikus elfogadási sorrendet.

Csak néhány választás valóban helyi, és azok soha nem befolyásolják az interoperabilitást: a belső tárolási elrendezés, a tárca seed-entrópiája és a tárca-oldali anchor-mélység K_wallet.

Bizonyítási rendszer. A profil Groth16-ot használ, ami áramkör-specifikus setupot igényel: az áramkör befagyasztása, egy trusted setup ceremónia, a bizonyító kulcs és az ellenőrző kulcs publikálása, és a kulcsanyag hozzárendelése a megfelelő ellenőrző azonosítóhoz. Bármely áramkör-módosítás megváltoztatja a setupot és ezzel mindkét kulcsot. A szerzők összehasonlítják a jelölteket: a Groth16 körülbelül 192 bájtos bizonyítást ad, a Polymath körülbelül 176-ot, a Pari körülbelül 160-at. Mivel minden envelope publikál egy bizonyítást, ezek a különbségek közvetlenül a lábnyom számokba folynak be.

Hordozó és méret. A profil pontosan egy OP_RETURN kimenetet használ a teljes bináris envelope hordozására. A darabolás több kimenetre, a witness-hordozás és az alternatív hordozó-helyek nem részei a profilnak. Az indexerek figyelmen kívül hagyják a witness bájtokat, amikor shielded envelope-okat nyernek ki.

A 2 bemenetes, 2 kimenetes konfiguráció mérete:

  • 6 bájtos header, 4 bájtos anchor, két egybájtos darabszám
  • 2 × 32 bájt nullifier, 2 × 32 bájt tömörített efemer kulcs
  • 2 × 67 bájt fogadói ciphertext
  • 144 bájt küldő-helyreállítási köteg (két 64 bájtos bejegyzés és egy 16 bájtos tag)
  • 192 bájt bizonyítás
  • Összesen 610 bájt szerializált protokoll-envelope

A minimálisan push-olt OP_RETURN script 614 bájt, a teljes szerializált Bitcoin kimenet 625 nem-witness bájt. Minden envelope-bájt négy súlyegységbe, azaz egy virtuális bájtba kerül ebben a hordozóban.

Összehasonlításként a szerzők egy konkrét witness-hordozó sablont számolnak ki: egy prepay/commit tranzakció, amely egy P2TR key-path bemenetet költ el és két P2TR kimenetet hoz létre (a script-path elköteleződést és a visszajárót), majd egy reveal tranzakció, amely az elköteleződést egy egy-leveles P2TR script pathon keresztül költi el. A két tranzakció együtt 438 vB, szemben az OP_RETURN 625 vB-jával. A witness-hordozás tehát nagyjából negyedére viszi a súlyköltséget, de egy két-tranzakciós prepay-reveal folyamat és saját standardness-feltevések árán.

Standardness-feltevés. A szerzők itt őszinték: az egy-kimenetes OP_RETURN publikáció relay- és bányászati politikai feltevés, nem konszenzusgarancia. A feltételezett környezet a Bitcoin Core v30.0-ban bevezetett enyhített -datacarriersize defaultot támogatja, amely 83-ról 100 000 bájtosra emelte a korlátot, és megengedi több OP_RETURN kimenetet tranzakciónként. Ez a default node-konfigurálható és nem univerzálisan elfogadott: az operátorok visszaállíthatják a történelmi 83 bájtos korlátot, ezért a legacy cap fölötti envelope-ok relay-je attól függ, hogy elég relay- és bányászcsomópont futtatja-e az enyhített politikát. Ez egy figyelendő telepítési tulajdonság.

Anchor-ablak. A profil ajánlott konstansai W := 100 és K_min := 1. Ezekkel a replay akkor fogad el egy H blokkban lévő jelölt átutalást, ha H - 100 ≤ a ≤ H - 1. A W = 100 a cél blokkintervallum mellett körülbelül tizenhat óra publikációs ablakot ad a bizonyítás elkészítése és a bekerülés között, ami lefedi a szokásos díjbecslést, újrasugárzást, késleltetett bekerülést és egyszerű relayer-munkafolyamatokat, miközben a megtartott gyökér-történet kicsi marad. A szerzők azt is javasolják, hogy a tárca-szoftver szigorúbb helyi anchor-politikát alkalmazzon K_wallet > K_min értékkel, és hogy a tárcák közös anchor-választási politikát használjanak, mert a szokatlan anchor-életkorok elkerülhető metaadat-különbségeket hoznak létre.

Tárca seed és diverzifikáló. A tárca gyökérbemenete egy egyenletesen véletlen 32 bájtos seed_wallet. A szerzők kifejezetten megjegyzik, hogy alacsony entrópiájú jelszavak nem alkalmasak tárca seedként. A fizetési címek 11 bájtos d diverzifikálót használnak, ami cím-névtér és kódolási választás: elég változatosságot ad ahhoz, hogy egy viewing kulcs alatt sok fogadási útvonalat osszanak ki, miközben a fizetési címek és a note-plaintextek tömörek maradnak. Ez nem önálló biztonsági paraméter a note-felismeréshez vagy a költéshez.

AEAD-követelmények. A szerzők figyelmeztetnek, hogy egy egyszerű AEAD nem elegendő. A fogadói csatornának elköteleződő AEAD-nak kell lennie (kulcs-elköteleződő és note-megnyitás-robusztus, azaz egy ciphertext nem nyílhat meg két kulcs alatt vagy két plaintextre) és kulcs-privátnak (a fogadó identitását a ciphertext nem fedi fel). A küldő-helyreállítási csatornának kulcs-privátnak kell lennie (a küldő identitását a ciphertext nem fedi fel), valamint bizalmasnak és ciphertext-integritást megőrzőnek.

Nyitott kérdések és a jövőbeli munka

A tanulmány záró része felsorolja, mi marad nyitva, és ez a lista önmagában informatív a rendszer érettségéről.

Telepítési paraméterek. A bizonyítási rendszer, a publikációs hordozó, az átutalás-aritás és a nyilvános állítás tartalma nem független egymástól. Együtt kereskednek az envelope lábnyomával, a bizonyítási költséggel és a privacy-halmaz méretével, és egy telepítési profil ezeket együtt rögzíti, nem egyenként. A szerzők egy 2-ről 2-re formátumot tartanak valószínű defaultnak, mert támogatja a visszajáróval járó fizetést, de nem választanak szabványos aritást, mert ahhoz a várható átutalás-minták és a padding konkrét költségének mérése kell.

Itt érdemes megjegyezni, hogy a szabványos aritás hiánya közvetlen adatvédelmi következménnyel jár: ha nincs egy szabványos aritás, a megfigyelő az átutalásokat a darabszámok alapján osztályozhatja.

Light client és ellenőrzött szinkron. A tárcának note-pozíciókra, Merkle-utakra és helyes blokk-szintű gyökérre van szüksége a költési bizonyítás építéséhez, és jelenleg három módon juthat megbízható nézethez: teljes helyi újrajátszással, egy indexer válaszának a Bitcoin-adatok elleni ellenőrzésével, vagy egy kiválasztott indexerre tett explicit bizalmi feltevéssel. A teljes újrajátszás drága, a bizalmi feltevés pedig gyengíti a garanciát azoknak a tárcáknak, amelyek nem tudnak újrajátszani. A nyitott kérdés az, hogy egy light client tud-e szoros bizonyítást adni arról, hogy R[h] az elfogadott envelope-ok helyes determinisztikus újrajátszása h magasságig, újrajátszás nélkül ellenőrizhetően. A szerzők szerint egy ilyen rekurzív vagy proof-carrying konstrukció lehetővé tenné egy view-only tárcának a gyökér helyességének ellenőrzését anélkül, hogy az indexert megbízható komponenssé emelné. Ez a szinkron- és bizalmi költséget csökkentené, de a láncköltséget nem, mert a költés továbbra is publikál egy hordozó tranzakciót és fizeti a Bitcoin díját.

A peg, mint külön tanulmány. A peg-in és a peg-out nincs specifikálva. A szerzők szándékolt iránya a PIPE-alapú határmenet: a közönséges Bitcoin-likviditás az L1-en köteleződik el, a belépési, kilépési és feloldási szabályok pedig Bitcoinhoz horgonyzott metaprotokoll-átmenetként jelennek meg, nem konszenzusváltoztatásként. A föderált vagy multisig letétkezelés, a BitVM-stílusú hidak és a jövőbeli covenant- vagy vault-alapú konstrukciók hasznos összehasonlítási pontok maradnak, de a belépés és kilépés bizalmi, élősségi, cenzúra-ellenállási és adatvédelmi tulajdonságai a határprotokollhoz tartoznak, nem az átutalási bizonyításhoz.

A szerzők itt egy gyakorlati szivárgási mintát is leírnak: egy megkülönböztető peg-in összeg, amelyet rövidesen shielded aktivitás követ, vagy egy későbbi peg-out korreláló összeggel és időzítéssel, összekapcsolást támogathat a note-titkosítás megtörése nélkül. Ugyanez a hatás érhető el ugyanazon híd-operátor, feloldási minta, díjforrás vagy kilépési szolgáltatás ismételt használatával.

Hálózati megfigyelés és mempool. Az elfogadott láncra vonatkozó adatvédelmi modell nem fedi le azt az erősebb támadót, amely a tranzakció eredetét, a mempool-terjedést, a sikertelen sugárzásokat, a helyettesítési kísérleteket vagy a csak árva blokkokban megjelenő envelope-okat figyeli. Ezek az észlelések időzítést, anchor-kort, aritást, díjstratégiát és újrapróbálkozási mintákat tárhatnak fel akkor is, ha a megfelelő átutalás soha nem fogadódik el a replay-ban. A mempool soha nem replay-állapot, de megfigyelési felület. A szerzők a hálózati réteg lehetséges eszközeiként említik a Dandelion és Dandelion++ sugárzási sémákat, valamint az onion-routing és mixnet rendszereket (Tor, Loopix), de hangsúlyozzák, hogy ezek külön hálózati támadómodellt igényelnek, és nem következnek a nulla-tudású átutalási bizonyításból.

Tárca-politika. A tárca viselkedése érdemben befolyásolhatja az adatvédelmet akkor is, ha a kriptográfiai protokoll helyes. A bemenetválasztás, a kimeneti aritás, a visszajáró elhelyezése, az anchor-választás, a publikációs időzítés, a relayer-választás, a kötegelt publikálás és az újraépítési konstrukció mind formálja a támadó posterior eloszlását a jelölt történetek fölött. Egy tárca, amely megkülönböztethető aritást, elavult anchort, determinisztikus visszajáró-pozíciót, ismétlődő díjforrást vagy determinisztikusan újraépített tranzakciókat használ, az effektív privacy-halmazt csökkentheti anélkül, hogy bármely átutalás-érvényességi szabályt megsértene. A szerzők szerint az aritás ezek közül a legerősebb kar, mert hatása túlnyúlik a tárca-politikán, egészen az áramkörig és a trusted setupig.

A fenntartott levél-hely bővítései. A note-levél fenntart egy használaton kívüli elköteleződési helyet, a h_aux-ot, amely a aux_null értékre van rögzítve és nem szerializálódik. Ez a kijelölt kötési pont azoknak a bővítéseknek, amelyeknek a note létrehozásakor kiegészítő adatot kell elkötelezniük anélkül, hogy az adat a note-plaintextbe kerülne. Az átutalási réteg nem értelmezi a helyet: egy bővítés definiálja a saját megnyitási relációját, egy kiterjesztett áramkörben bizonyítja, és a kiegészítő nyilvános adatot a saját envelope-formátumában hordozza, nem az alap e-ben. A motiváló példa egy atomi swap egy shielded note és átlátszó Bitcoin között, amely h_aux-ba köti a hash-lockot.

Opcionális KYC-evidencia. A D függelék egy meglepő és figyelemreméltó irányt vázol fel: egy opcionális nulla-tudású lineage réteget, amellyel egy intézmény helyben ellenőrizheti, hogy egy bejövő note jóváhagyott Bitcoin-bemenetekből származik-e, és hogy a későbbi privát átutalások hitelesített fogadókon belül maradtak-e. A konstrukció lényege: egy Trust Authority igazolja a jóváhagyott Bitcoin-bemeneteket és hitelesít konkrét shielded PaymentAddress értékeket. Egy certified-lineage kimenet rekurzív bizonyítást hordoz arról, hogy a gyökerei hitelesített peg-inek, hogy minden megőrző átutalás csak érvényes lineage-szal rendelkező bemenetet használt, és hogy a kimenet a hitelesített fogadói címre készült. A Bitcoin konszenzus és az alap replay nem értelmezi; a lineage-evidencia nélküli note-ok érvényes Shielded Bitcoin note-ok maradnak.

A szerzők három részletet emelnek ki, amelyek módszertanilag fontosak. Az első: a lineage-package a fogadó-titkosított note-adatban utazik, és a valódi lineage-evidencia és a dummy payload ugyanazt a kódolást és hosszúságot használja, ezért a fogadó viewing kulcsa nélküli megfigyelő a ciphertextből nem tudja megkülönböztetni őket. A második: a certified-lineage tulajdonság csak akkor őrződik meg, ha az átutalás minden felemésztett bemenete érvényes package-dzsel rendelkezik. Egy olyan átutalás, amely egyszerre fogyaszt certified-lineage note-ot és közönséges note-ot, érvényes marad az alapprotokoll szerint, de egyetlen kimenete sem tarthatja meg a certified-lineage állítást. A harmadik: az authority-tanúsítvány egy adott szabályzati korszakban hozott döntést rögzít, nem a jelenlegi ellenőrt vagy haszonélvező tulajdonost; a jelenlegi állapotra vonatkozó állításhoz authority-hitelesített állapot-pillanatkép és szabályzati korszak kell a rekurzív állításban, enélkül az evidencia csak a kiadáskori jóváhagyást igazolja.

Forrás

  • Tanulmány: https://www.allocinit.xyz/uploads/shielded-bitcoin.pdf (Clara Shikhelman, Mikhail Komarov, Aleksei Moskvin, [[alloc] init], 2026-09-24, 55 oldal)
  • Kutatócég oldala: https://www.allocinit.xyz/research
  • Kulcsszavak: Shielded Bitcoin, shielded note, nullifier, nulla-tudású bizonyítás, determinisztikus replay, metaprotokoll, PIPEs v2, witness encryption, Groth16, OP_RETURN hordozó, anchor-ablak, note tree, szivárgási függvény, privacy-halmaz, tárca-kulcshierarchia, viewing key, certified-recipient lineage
  • Alkalmazhatóság: KÖZEPES. A tanulmány Bitcoin-protokolltervezési dokumentum, nem rendszerterv a mi infrastruktúránkhoz. A közvetlenül átvihető elemek a szerkezetiek: az olvasási és írási képességek szétválasztása, a determinisztikus újrajátszás mint állapotforrás, az explicit szivárgási függvény mint az adatvédelmi állítások kerete, és a fenntartott bővítési hely mint visszafelé kompatibilis kiterjesztési pont.
  • Megjegyzés a mérési adatokról: a tanulmány specifikáció és elemzés, nincs telepített hálózat, és a szerzők nem közölnek működési méréseket. A biztonsági és adatvédelmi állítások a megadott feltevések mellett érvényesek (bitcoin ledger feltevés, őszinte setup, kanonikus implementáció, őszinte tárca-viselkedés), és nem független verifikáción alapulnak. A peg-mechanizmusról szóló sajtóbeszámolókban szereplő számok (körülbelül 700 vB shielded tranzakciónként, nagyjából 8 TB-ra csökkentett titkosított fájlok a witness encryptionhöz) nem a tanulmányból származnak, hanem Misha Komarov 2026. szeptember 10-i interjújából, ezért másodlagos forrásként kezelendők.

Kapcsolódó külső források

Kapcsolódó belső források

  • 2026-09-22_bitcoin_optech_newsletter_423_recap.md, a Bitcoin Optech legutóbbi feldolgozott epizódja: az unspendable internal keys draft BIP (NUMS-pont), a Covenants.diy covenant-szerkesztő és a BitBoxApp Spark-integráció közvetlenül ugyanabban a tervezési térben mozog, mint ez a tanulmány. Az epizód Murch-féle megkülönböztetése a "nem-kasztodiális" elnevezés félrevezető voltáról pontosan az a kérdés, amit ez a tanulmány a metaprotokoll-szintű nem-kasztodiális állításánál óvatosan kezel.
  • 2026-05-13_bitcoin-privacy-panel.md, a Bitcoin adatvédelmi eszközeinek panelje: a CoinJoin, PayJoin és Silent Payments korlátai, amelyeket ez a tanulmány a related work szekcióban rendszerez
  • 2023-03-14_lightning_network_privacy_explainer_voltage.md, a Lightning adatvédelmi modellje, mint a nem-láncon-validált réteg korábbi tárgyalása
  • 2026-09-21_polylane_prevent_slop_hitting_prod.md, módszertani párhuzam: a Polylane cikk háromállapotú ítélete (confirmed/plausible/refuted) és ennek a tanulmánynak a szivárgási függvénye ugyanazt a fegyelmet képviseli: előbb definiáld, mit tud a megfigyelő, aztán fogalmazz állítást
  • 2025-12 Recursive Language Models, a rekurzív bizonyítási konstrukció elvi háttere, ami a light client verified sync nyitott kérdéséhez kapcsolódik

Hogyan kapcsolódik a saját rendszerünkhöz?

Három szerkezeti párhuzam van, és egy, ami közvetlenül érinti a saját adatvédelmi álláspontunkat.

Az olvasási és írási képességek szétválasztása. A tanulmány kulcshierarchiája a költési jogosultságot, a bejövő megtekintést és a kimenő helyreállítást külön ágakra bontja, és a felfedési modell kizárólag olvasási képességeket ad ki. A szerzők ezt a hierarchia szülőviszonyaival érik el, nem ígéretekkel: a sk_nf a ser(sk_spend) gyermeke, a vk_in szintén az, de csak olvasható, a vk_out pedig a sk_master-nél válik szét, és soha nem ad sk_spend-et vagy sk_nf-et. Ez a minta közvetlenül ismerős: a saját skill- és eszközrendszerünkben is az a helyes elv, hogy a hozzáférési szint a struktúrából következzen, ne a használat szándékából. A tanulmány ezt formálisan is megfogalmazza: "egyetlen felfedési anyag sem tartalmaz seedet, költési kulcsot vagy nullifier-kulcsot", és a sk_nf kizárásának az a célja, hogy a felfedés ne váljon általános összekapcsoló eszközzé. Ez ugyanaz a logika, mint a saját napló- és bizonyíték-kezelésünkben: a bizonyíték megadása ne adjon egyben cselekvési jogosultságot.

A determinisztikus újrajátszás mint állapotforrás. A tanulmány központi állítása, hogy két helyes implementáció, ugyanazon a bemeneten futva, koordináció nélkül ugyanahhoz az állapothoz jut, és ezért nincs szükség vitarendezésre. Ez pontosan az a tulajdonság, amire a saját tudásbázis-építésünk is törekszik: a a kanonikus forrás, és a wiki raw, az indexek és a topic-bejegyzések ebből determinisztikusan származnak. A tanulmány ehhez ad egy hasznos fegyelmezési szabályt: ami nem determinisztikus, az nem lehet az elfogadási predikátum része. Nálunk ugyanez a kérdés merül fel a szerkesztési döntéseknél: ha két futtatás eltérő eredményt ad ugyanarra a bemenetre, akkor az a lépés nem tartozhat a "kanonikus" részbe.

A fenntartott bővítési hely. A note-levél h_aux mezője jelenleg a aux_null konstansra van rögzítve és nem szerializálódik, de a szerzők már most kijelölik a jövőbeli bővítések kötési pontjaként, és a kódolást úgy rögzítik, hogy a bővítés ne törje meg a kanonikus szerializációt. Ez a visszafelé kompatibilis kiterjesztés minta, amit a saját skill-frontmatterünkben és a canonical FOOTER struktúrában is alkalmazunk. A tanulmány ehhez hozzátesz egy éles megszorítást: a bővítés a saját megnyitási relációját definiálja, és a saját envelope-formátumában hordozza az adatot, nem az alapban. Vagyis a fenntartott hely csak elköteleződési pont, nem tároló.

A KYC-lineage függelék és a saját álláspontunk. Ez az a rész, ahol a legélesebb a különbség a technikai érdekesség és a saját elveink között. A D függelék egy olyan konstrukciót vázol fel, amely nulla-tudású bizonyítással igazolja, hogy egy note jóváhagyott Bitcoin-bemenetből származik, és hogy a későbbi átutalások hitelesített fogadókon belül maradtak. Technikailag elegáns: a bizonyítás nem fedi fel a korábbi címeket, a tartókat és az átutalási gráfot, és a dummy payloadok azonos hosszúságúak, ezért a láncon nem megkülönböztethetők. A szerzők maguk is pontosan megjelölik a határt: az állítás az issuer, a szabályzati korszak és az ellenőrzött követelés szintjén továbbra is felfedi a döntést, és nem mond semmit a Bitcoin-történelemről a jóváhagyott bemenetek előtt, sem a tanúsítványban szereplő cím jelenlegi tulajdonosáról. A saját álláspontunk szerint ez a rész az, amit a legszorosabban kell figyelni: egy opcionális, de protokoll-szinten támogatott lineage-réteg könnyen válik a következő években de facto elvárássá, és akkor a "nem mainnetre" jellegű önkéntesség eltűnik. A tanulmány legalább őszintén jelzi, hogy opcionális és hogy a base protocol szerint a lineage nélküli note is érvényes.

Vissza a tetejére