Pokračujeme v našem cyklu o fungování blockchainu Monero a dnešní článek bude věnován protokolu RingCT (Ring Confidential Transactions), který představuje důvěrné transakce a nové ringové podpisy. Bohužel na internetu je málo informací o tom, jak to funguje, a pokusili jsme se tuto mezeru vyplnit.
Budeme hovořit o tom, jak díky tomuto protokolu síť skrývá částky převodů, proč bylo opuštěno klasické ringové podpisy pro cryptonote a jak se tato technologie bude dále vyvíjet.
Protože tento protokol je jednou z nejkomplexnějších technologií v Monero, čtenář bude potřebovat základní znalosti o fungování tohoto blockchainu a povrchové znalosti v kryptografii na eliptických křivkách (k osvěžení těchto znalostí si můžete přečíst první kapitoly našeho předchozího článku o ).
Protokol RingCT
Jedním z možných útoků na cryptonote měny je analýza blockchainu založená na znalosti částky a času odeslané transakce. To umožňuje výrazně zúžit oblast hledání zajímajících úniků pro útočníka. Pro ochranu před takovou analýzou byl v Monero zaveden protokol anonymních transakcí, který zcela skrývá částky převodů v síti.
Je výstižné poznamenat, že myšlenka skrývání částek není nová. Jedním z prvních, kdo ji popsal, je vývojář Bitcoin Core Greg Maxwell ve svém . Současná realizace RingCT je modifikací s možností použití ringových podpisů (jak by to mohlo být bez nich) a proto získala svůj název — Ring Confidential Transactions.
Kromě jiného protokol pomáhá zbavit se problémů s mixováním „prachových“ výstupů — výstupů s malou částkou (obvykle vznikající jako drobné z transakcí), které vytvářely více problémů, než kolik stály samy.
V lednu 2017 došlo k hard forku sítě Monero, který umožnil volitelné používání důvěrných transakcí. A již v září téhož roku se z hard forku verze 6 staly takové transakce jediné povolené v síti.
RingCT využívá hned několik mechanismů: multilayered linked spontaneous anonymous group signatures (MLSAG), schéma závazků (Pedersen Commitments) a range proofs (pro tento termín neexistuje ustálený překlad do češtiny).
Protokol RingCT zavádí dva typy anonymních transakcí: simple a full. První typ generuje peněženka, když transakce využívá více než jeden vstup, druhý je použit v opačné situaci. Různí se validací částek transakcí a podpisovanými daty s MLSAG podpisem (více o tom budeme hovořit níže). Přičemž transakce typu full lze generovat s jakýmkoli počtem vstupů, v zásadě zde není žádný rozdíl. V knize se uvádí, že rozhodnutí omezit full transakce na jeden vstup bylo učiněno narychlo a v budoucnu se může změnit.
MLSAG podpis
Připomeňme si, co představují podepisované vstupy transakce. Každá transakce utrácí určité prostředky a generuje. Generace prostředků probíhá vytvářením výstupů transakce (přímá analogie — bankovky), a výstup, který transakce utrácí (ve skutečném životě utrácíme skutečně bankovky), se stává vstupem (pozor, zde se velmi snadno zamotáte).
Vstup odkazuje na několik výstupů, ale utrácí pouze jeden, čímž vytváří „dýmovou clonu“, aby ztížil analýzu historie převodů. Pokud má transakce více než jeden vstup, lze tuto strukturu představit jako matici, kde řádky jsou vstupy a sloupce jsou zapojené výstupy. Aby se síti dokázalo, že transakce utrácí právě své výstupy (zná jejich tajné klíče), vstupy podepisují kruhovým podpisem. Tento podpis zaručuje, že podepisující znal tajné klíče od všech prvků v nějakém sloupci.
Ochranné transakce již nepoužívají klasické pro kruhové podpisy, místo nich se objevily MLSAG — adaptace pro více vstupů obdobných jednovrstvých kruhových podpisů, .
Několik vrstev se nazývá, protože podepisují ihned několik vstupů, z nichž každý je zamíchaný s několika dalšími, tj. podpisuje se matice, nikoli jeden řádek. Jak uvidíme později, to pomáhá šetřit na velikosti podpisu.
Podívejme se, jak se vytváří kruhový podpis, na příkladu transakce, která utrácí 2 skutečné výstupy a používá k zamíchání m — 1 náhodné z blockchainu. Označme veřejné klíče výstupů, které utrácíme, jako
, a key images pro ně odpovídajícím způsobem: 
Takže máme matici o velikosti 2 x m. Nejprve je třeba vypočítat takzvané výzvy pro každou dvojici výstupů:
Vypočítání začínáme s výstupy, které používáme, pomocí jejich veřejných klíčů:
a náhodná čísla
Na konci získáme hodnoty:
, které použijeme pro výpočet výzvy
následující dvojice výstupů (abychom usnadnili pochopení, co kam vkládáme, zvýraznili jsme tyto hodnoty různými barvami). Všechny další hodnoty se počítají v kruhu podle vzorců uvedených na první ilustraci. Poslední se počítá výzva pro pár skutečných výstupů.
Jak vidíme, ve všech sloupcích, kromě toho obsahujícího skutečné výstupy, se používají náhodně generovaná čísla
. Pro π-tý sloupec to také potřebujeme. Převádíme
na s:
Samotný podpis představuje n-tici všech těchto hodnot:
Dále jsou tato data zapsána do transakce.
Jak vidíme, MLSAG obsahuje pouze jednu výzvu c0, což umožňuje ušetřit na velikosti podpisu (které i tak vyžadují hodně místa). Dále každý kontrolor, pomocí dat
, obnovuje hodnoty c1,…, cm a kontroluje, že
. Takže se naše kruh uzavřel a podpis prošel kontrolou.
Pro ringCT transakce typu full se k matici s zamíchanými výstupy přidává ještě jeden řádek, ale o tom si povíme níže.
Pedersenova potvrzení
(častěji se používá anglický termín — commitments) se používají k tomu, aby jedna strana mohla dokázat, že zná nějaké tajemství (číslo), aniž by ho vlastně odhalila. Například hodíte na kostkách nějaké číslo, spočítáte závazek a předáte ho kontrolní straně. Takže v okamžiku odhalení tajného čísla kontrolor sám znovu spočítá závazek a tím se ujistí, že jste ho nepodvedli.
V Moneru se závazky používají k utajení částek převodů a používají nejrozšířenější variantu — Pedersenova potvrzení. Mimochodem, zajímavý fakt — původně vývojáři navrhovali skrýt částky běžným zamícháním, tedy přidávat výstupy na libovolné částky, aby vytvořili nejistotu, ale později přešli na závazky (přitom není jisté, že ušetřili na velikosti transakce, jak uvidíme níže).
Obecně závazek vypadá takto:
Kde C — hodnota samotného závazku, a — skrývaná částka, H — pevný bod na eliptické křivce (další generátor), a x — nějaká libovolná maska, skrytý faktor, generovaný náhodně. Maska zde slouží k tomu, aby třetí strana nemohla jednoduchým zkoušením zjistit hodnotu commitmentu.
Při generování nového výstupu peněženka počítá commitment, a při výdeji buď vezme hodnotu vypočtenou při generování, nebo ji přepočítá znovu — v závislosti na typu transakce.
RingCT simple
V případě simple RingCT transakcí je nutné zajistit, aby transakce vytvořila výstupy o sumě rovné sumě vstupů (neprodukovala peníze z ničeho), a proto musí být součet commitmentů prvních a druhých stejný, tedy:
Commitmenty poplatků se počítají poněkud jinak — bez masky:
, kde a — součet poplatku, je veřejně dostupný.
Takový přístup umožňuje prokázat kontrolní straně, že používáme stejné částky, aniž bychom je odhalili.
Abychom to vše lépe pochopili, zvažme příklad. Předpokládejme, že transakce utrácí dva výstupy (tedy se stávají vstupy) ve výši 10 a 5 XMR a generuje tři výstupy v celkové hodnotě 12 XMR: 3, 4 a 5 XMR. Přičemž platí poplatek 3 XMR. Takže celková částka utracených peněz plus součet vygenerovaných a poplatku je rovna 15 XMR. Pokusme se vypočítat commitmenty a podívat se na rozdíl jejich součtů (vzpomněli jsme na matematiku):
Zde vidíme, že aby se rovnice shodovala — součty masek vstupů a výstupů musí být stejné. K tomu peněženka generuje náhodně x1, y1, y2 a y3, a zbývající x2 vypočítává takto:
Použitím těchto masek můžeme každému kontrolorovi prokázat, že negenerujeme více prostředků, než utrácíme, aniž bychom odhalili částky. Originální, že?
RingCT full
V full RingCT transakcích kontrola součtů převodů probíhá o něco složitěji. U těchto transakcí peněženka nepřepočítává commitmenty pro vstupy, ale používá vypočítané při jejich generování. Při tom musíme předpokládat, že rozdíl součtů už nedostaneme rovný nule, a místo toho:
Zde od — rozdíl masek vstupů a výstupů. Pokud zvažujeme zG jako veřejný klíč (čímž de facto je), pak od — to je soukromý klíč. Tím pádem známe veřejný a odpovídající soukromý klíč. Mít tyto údaje nám umožňuje je použít v kruhovém podpisu MLSAG spolu s veřejnými klíči zamíchaných výstupů:
Platný kruhový podpis tak zaručí, že známe všechny soukromé klíče jednoho z sloupců, a soukromý klíč v posledním řádku můžeme znát pouze pokud transakce nevytváří prostředky více, než kolik utrácí. Mimochodem, zde je také odpověď na otázku „proč zde rozdíl mezi součty commitments není nula“ — pokud zG = 0, odhalíme sloupec s reálnými výstupy.
A jak se příjemce peněz dozví, kolik mu bylo zasláno? Tady je to jednoduché — odesílatel transakce a příjemce si vymění klíče podle protokolu Diffie-Hellman, používají klíč transakce a view-klíč příjemce a vypočítají společné tajemství. Odesílatel zapíše do speciálních polí transakce údaje o částkách výstupů, zašifrované tímto společným klíčem.
Range proofs
A co se stane, pokud použijeme záporné číslo jako částku v commitments? To může vést k vytváření dalších mincí! Takový výstup není přípustný, proto je potřeba záruka, že použité částky nejsou záporné (bez odhalení těchto částek, samozřejmě, jinak by tolik práce bylo zbytečné). Jinými slovy, musíme prokázat, že částka se nachází v intervalu [0, 2n — 1].
K tomu je každá částka výstupu rozdělena na binární číslice a pro každou číslici se počítá commitment zvlášť. Jak to probíhá, je nejlepší ilustrovat na příkladu.
Představme si, že částky jsou malé a vejdou se do 4 bitů (v praxi to je 64 bitů), a vytváříme výstup na částku 5 XMR. Vypočítáme commitments pro každou číslici a celkový commitment na celou částku:
Dále je každý commitment zamíchán s náhradním (Ci-2iH) a párově podepsán kruhovým podpisem Borromea (další kruhový podpis), který navrhl Greg Maxwell v roce 2015 (podrobněji o něm se lze dočíst ):
To vše se nazývá range proof a zaručuje, že v commitments jsou použity částky v intervalu [0, 2n — 1].
Co dál?
V aktuální implementaci range proof zabírá velmi mnoho místa – 6176 bajtů na jeden výstup. To vede k velkým transakcím a odpovídajícím vyšším poplatkům. Aby se snížila velikost transakce, vývojáři Monera zavádějí místo Borromeových podpisů bulletproofs – mechanismus range proof bez bitových commitments. , dokážou zkrátit velikost range proof až o 94 %. Mimochodem, v polovině července technologie prošla od společnosti Kudelski Security, která neodhalila zásadní nedostatky jak v samotné technologii, tak v její implementaci. Technologie je již aplikována v testovací síti a s novým hard forkem by pravděpodobně mohla přepracovat i do hlavní sítě.
Ptejte se na své otázky, navrhujte témata pro nové články o technologiích v oblasti kryptoměn a také se přihlaste do naší skupiny na , abyste byli v obraze o našich událostech a publikacích.
Zdroj: habr.com
