Тази седмица ще навлезем в малко повече подробности относно несвързаността на DBC и какви са последиците и компромисите от това за потребителското изживяване и ефективността на мрежата.
Общ напредък
Старейшина е специален вид възел с права на глас и управленски задължения, докато Възрастен възел съхранява данни и ги доставя при поискване, но за клиента те изглеждат абсолютно еднакви. @chris.connelly работи върху някои грешки, които виждат клиент, който се опитва да стартира към Възрастен, който след това го игнорира, създавайки неработещ цикъл.
Крис също работи по подобряване на инструмента sn_launch (както забелязаха някои от вас!) и отстраняване на грешки при надстройката на qp2p.
@JimCollinson разглежда въпроса за идентификационните данни, използвайки множество подписи, за да може да добави още опции за удостоверяване към основната парола/мнемоника, включително хардуерни ключове, допълнителни мнемоники или начални фрази и т.н. Например, потребителят може да заяви, че за отключване на Сейф трябва да бъдат представени три или пет идентификационни данни. Множество от подписи също отваря вратата за използване на n доверени трети страни за възстановяване на акаунт. Потребители използващи Safe мрежата неизбежно ще загубят идентификационни данни, а множество от подписи предлага начин за сигурно възстановяване на акаунта, позволяващ на потребителя да контролира баланса на риска, както сметне за добре.
@bochaco разглежда как Клиентът валидира, че секцията, с която говори, е актуална чрез AE.
@Qi_Ma разглежда какво се случва, когато пространството във Възрастните възли се запълни. Понастоящем има някакво ненормално поведение в начина, по който следващият алтернативен не запълнен Възрастен възел се избира да съхранява парче от Старейшините и как Старейшините знаят къде е парчето, като се има предвид, че вече не е най-близкото до XOR името на парчето.
Междувременно @chriso работи по модернизирането на API-то, за да се вземат предвид новите промени в съобщенията, задача, която вече е почти завършена.
Работата на @oetyng с интегрирането на подсиленото „самокриптиране“ заедно с преструктурирането за обработка на парчета е обединена. Двойството на обхвата (публично/частно) е преместено от ниво на парче на ниво blob - опростявайки значително задълженията на кода и възлите. Също така е добавено правилното боравене с дефакто секретния ключ, който самокриптирането извежда заедно с криптираните парчета. С това на място работата по груповото обединение на парчета вече може да продължи.
Също така обединихме клона на функциите ни в процес на работа в основния клон (или по-скоро преместихме HEAD на main към това, ако искате да влезете в git подробностите…). Това означава, че клонът е по-стабилен от основния. Виждаме повече преминаващи CI и много по-чист код като цяло. В този клон има много добавени неща и все още тестваме, и отстраняваме грешки в различните потоци. Но с AE навсякъде и по-опростен поток на кода във възела, всичко това става все по-лесно, докато напредваме. Така че, въпреки че все още няма тестова мрежа, с която да си поиграете, ние вървим в правилната посока.
Още за DBC
Продължавайки нашата поредица за DBC, тази седмица се задълбочаваме в свойството *несвързаност *. Обсъждаме защо е важно и преглеждаме различни начини, по които криптовалутите, фокусирани върху поверителността, се опитват да го постигнат.
Надяваме се, че този преглед може да предостави на читателите повече контекст и опит за технологиите, които разглеждаме, като например нулеви доказателства за знания, сляпо подписване, ангажименти, фиксирани деноминации и т.н.
Несвързаност
И така, защо е важно паричният токен да бъде несвързан? Накратко, защото това е техническото средство за постигане на по-общото и много желано парично свойство на заместимост. Заменяемостта означава, че един знак е взаимозаменяем с друг.
Помислете за две немаркирани златни кюлчета с еднакво тегло. Всяко едно е също толкова добро, колкото всяко друго. Те са неразличими едно от друго. Въпреки това, ако тези кюлчета са маркирани със серийни номера и някаква централна организация поддържа списък на всички борси за злато, проследени по серийния номер, тогава можем да имаме ситуация, в която едно кюлче струва по-малко от друго в съзнанието на потенциалните купувачи, защото е било свързано с някаква „лоша“ дейност в миналото. Или друго може да е още по-ценно, защото е преминал през ръцете на известна личност. При такава система участниците може да започнат да губят доверие в златните кюлчета. Може да се наложи да проверяват срещу централизиран „добър/лош списък“ за всяка транзакция, за да предотвратят получаването на „лошо кюлче“ и цялостната система става по-малко ефективна. Поради проследяването сме загубили заместимост. За повече информация вижте горепосочената статия.
Има и много последици за загуба на поверителност при получаване или извършване на плащане с токен, който има дълга история. Safe мрежата се стреми да позволи частни, безопасни транзакции за всички участници в мрежата.
Как можем да определим дали дадена монета е свързана или несвързана? Всъщност е доста лесно, просто разглеждаме входовете и изходите на чифт транзакции.
Забележка: В случая на DBC често използваме думите транзакция и преиздаване взаимозаменяемо
Ето един опростен пример за две преиздавания, използващи настоящата ни DBC система. Можем да кажем, че Боб е платил 50 на Алис (първото преиздаване), а след това Алис е платила същите 50 на Джим (второ преиздаване). Така че всяко преиздаване има само един входен DBC и един изходен DBC. Всеки DBC има свързана *сума *, публичен ключ на собственика pubkey и подпис на монетния двор mintsig. В този пример pubkey, mintsig и hash са съкратени до 3 цифри за краткост. В действителност те са много големи уникални числа.
reissue 1 (r1):
→ input = a {amount=50, pubkey = 567, mintsig=233}, hash(a) = 223
→ output = b {amount = 50, pubkey = 725, mintsig=112}, hash(b) = 787
reissue 2 (r2):
→ input = b {amount = 50, pubkey = 725, mintsig=112 }, hash(b) = 787
→ output = c {amount = 50, pubkey = 212, mintsig=455}, hash(c) = 993
Забележка: a, b и c са етикети за този пример. Те не се появяват при преиздаване. Сумите сега са скрити от ангажименти, но не са от значение за този анализ.
Лесно можем да видим, че вход b за r2 съвпада с изход b за r1. Можем да ги свържем заедно с някой от: pubkey == 725 или mintsig == 112, или хеш == 787.
Това установява, че преиздаванията r1 и r2 са свързани заедно, защото споделят общ DBC. При поредица преиздавания това създава верига, която може да бъде проследена.
Това се разбира под свързана монета.
Също така, ако сумата е с много уникална стойност (или стойностен ангажимент), тя може да се използва за свързване на транзакции.
Важен момент, който трябва да се отбележи е, че дори ако премахнем полетата pubkey и mintsig и просто използваме поле с произволен идентификатор (за да предотвратим двойно изразходване), DBC-тата все още могат да бъдат идентифицирани по тяхната хеш стойност. С други думи, ако същите данни се използват като изход за едно преиздаване и като вход за друго, тогава преиздаванията могат да се свързват. Това е валидно обобщение за всяка криптовалута, замествайки думата транзакция с преиздаване.
Може да попитате: какво ще стане, ако използваме множество входове и изходи и различни суми за разделяне и обединяване на монети? Е, такива техники могат да затруднят проследимостта на отделна монета. Това е в основата на CoinJoin, CoinShuffle и подобни алгоритми за смесване. Те правят повече възможните връзки, които да се следват/анализират. Но те всъщност не прекъсват никакви връзки … които се запазват за неопределено време, за да може всеки да анализира в свободното си време, използвайки статистически анализ, данни от трети страни (например борси) и т.н. Такива техники обикновено се считат за “слаб сос” от криптографите.
Можете също така да попитате: Защо изобщо има някакъв уникален идентификатор в DBC? Отговорът е, че идентификаторът е необходим, за да се предотвратят двойните разходи. Монетният двор трябва да може да запише „монета“ като изразходвана, за да улови всеки бъдещ опит да се похарчи отново.
След като вече разбираме термина свързаност, можем да започнем да мислим за начини за предотвратяването му.
Система със свойството несвързаност няма да има такива връзки. Големият въпрос е как да постигнем това свойство?
Слепи подписи
Най-старата известна техника е изобретена от Дейвид Шаум и е известна като Слепи подписи. Тя има предимството, че е най-простата схема за изпълнение и поне засега най-ефективната, което я прави много подходяща за операции в монетен двор.
Нека прегледаме основната концепция за сляп подпис. Докладът на Шаум използва примера за политически избори, проведени от разстояние. Тук представяме съкратена версия, въпреки че тази на Шаум също си струва да се прочете.
Сляп подпис е като поставяне на „листче“ със съобщение (например при гласуване) вътре в „плик“, облицован с въглерод. Мери изпраща „плика“ с „листчето“ вътре и обратен адрес на длъжностното лице по изборите Чарлз. Чарлз подписва „плика“ (който също подписва „фиша“ вътре) и го изпраща обратно. На по-късна дата Мери премахва „листчето“ за гласуване и го изпраща обратно на Чарлз в нов „плик“, но без обратен адрес. Чарлз отваря „плика“, премахва „листчето“, проверява дали има валиден подпис от Чарлз и преброява гласовете - без да знае кой е гласувал този конкретен вот или кога е бил подписан (сред набора от подписани пликове).
Ключовият момент е, че няма връзка между това, което е на някой от листчетата, и това, което е написано на някой от пликовете. Така че гласовете, подадени от всеки от гласоподавателите, не са известни на изборния служител Чарлз. (с изключение на специалистите по разчитане на подчерци и т.н. и т.н., които не са от значение за криптографски дискусии).
Добре, така че нека отново извършим двете ни преиздавания, този път с помощта на слепи подписи. Сега DBC Mint сляпо подписва плика (пликовете). За този пример приемаме, че всички DBC са еднакви по стойност.
reissue 1 (r1):
→ input = a.slip {pubkey = 567, mintsig=233}, hash(a.slip) = 223
→ output = b.envelope {blind(b.slip)}, hash(b.envelope) = 565
reissue 2 (r2):
→ input = b.slip {pubkey = 445, mintsig=112 }, hash(b.slip) = 787
→ output = c.envelope {blind(c.slip)}, hash(c.envelope) = 993
В думи:
- Боб представя вход A (листче) към монетен двор (с валиден знак на монетен двор над A) и получава подписа на мента върху изход B (плик) с монетен знак, показващ, че B струва същото като A (листче).
- Ментата също отбелязва A (листче) като изразходван.
- Боб премахва B (листче) от B (плик) и го дава на Алиса, която представя B (листче) на ментата и получава знака на мента върху C (плик) на стойност, същата като B (листче).
- Ментата също отбелязва B (листче) като изразходван.
Интересното тук е, че B (плик) има различен хеш от B (листчето) вътре в него. 565 != 787
Следователно, хешовете не съвпадат между tx1 и tx2 и нито полетата. Нищо не свързва тези две транзакции заедно, доколкото монетният двор може да види. Имаме несвързаност!
Вериги за нулево знание
По-модерен подход към транзакциите, които не могат да се свържат, е чрез използването на вериги за защита от нулеви познания (ZK) или ZCash.
С ZK доказателствата се опитваме да убедим Монетен двор в нещо, без да разкриваме чувствителна информация. ZK верижните системите за защита като PLONK се появиха през последните няколко години като общи системи за проектиране на ZK доказателства.
Например, да кажем, че прилагаме ZK верига, която симулира sha3_256. Тази схема ще ни позволи да докажем на трета страна, че знаем данните, които хешират до някакъв хеш, без да разкриваме самите данни. Можем дори да докажем свойства за тези данни!
Да кажем например, че данните, които хешираме, всъщност са цяла транзакция за повторно издаване.
let reissue = Reissue {
inputs: { Dbc {amount: 9, owner: pk1,..}, Dbc {amount: 1, owner: pk2,..},
outputs: { Dbc {amount: 10, owner: pk3,..}
ownership_proofs: {pk1_sig, pk2_sig}
};
Мога да пусна това преиздаване през sha3_256, за да генерирам хеш: tx_hash = sha3_256 (преиздаване).
За да убедим монетния двор, че това е хеш на валидна транзакция, можем да генерираме ZK доказателство, използвайки нашата sha3_256 верига.
ZK веригата има частни и публични входове, в този пример информацията за преиздаването ще бъде частни входове, а tx_hash ще бъде публичен вход.
private: [9, pk1, 1, pk2, 10, pk3, pk1_sig, pk2_sig]
public: [tx_hash]
Можем да запишем ограничения на тези частни/публични входове, тези ограничения са зададени в ZK верига, която след това може да бъде пусната, за да се получат доказателства, че тези ограничения са удовлетворени
/// Reissue Constraints
private[0] + private[2] = private[4] // 9 + 1 = 10
private[1].verify(private[0..6], public[6]) // pk1 signed the transaction
private[3].verify(private[0..6], public[7]) // pk2 signed the transaction
public[0] = sha3_256(private) // reissue data hashes to tx_hash
Забележка: препращаме входовете по техния индекс, схемите имат предварително определен размер, този размер ограничава броя на входните / изходните DBC, които можем да преиздадем в рамките на една транзакция за преиздаване.
Сега, след като кодираме тези ограничения като ZK верига, можем да вмъкнем подробностите за преиздаването в частните входни слотове и tx_hash в публичния входен слот на веригата. След това завъртаме манивелата, за да представим доказателство, че всички ограничения са изпълнени.
Важното е, че това доказателство не показва никаква информация за частните входове, можем да изпратим това доказателство заедно с tx_hash на монетния двор и той би бил убеден, че tx_hash е хеш от валидна транзакция. След това монетният двор може да подпише tx_hash, за да удостовери преиздаването.
Това е много готино, но изследванията в тази област са все още от скоро и инструментите около тези ZK системи на веригата все още са доста незрели. Доказателствата обикновено се произвеждат и проверяват много бавно, особено за сложни схеми като sha3_256.
Ако искате да погледнете по-дълбоко тази поредица е доста добра.
Кръг от подписи
Кръг от подписи, както се използва в Monero и други криптовалути, е метод за скриване на историята на транзакциите, като се крие в група.
В кръг подпис Алиса подписва транзакция, използвайки (1) частния ключ на Алиса, (2) публичния ключ на Алиса и (3) публичните ключове на други хора. Всеки може да провери подписа на Алиса с помощта на набора от публични ключове, но те (обикновено) не могат да определят кой е истинският подписващ, тъй като има множество еквивалентни публични ключове.
Като такива, подписите с пръстен са форма на автоматично смесване. Връзките все още съществуват, но има толкова много от тях, че може да е твърде трудно да се анализират. В момента Monero има 11 възможни подписали: истинския плюс 10 други. Така че това е все едно да се скриеш в тълпа от 11 души … по-добре от това да стоиш сам, но не е супер успокоително, ако кръвожадно куче души наоколо.
Скриване на сумата
Скриване на суми, известно също като Поверителни транзакции също помага за подобряване на поверителността, но не засяга [не]свързването.
Скриване на сумата е съвместимо с zk вериги и пръстенови подписи, но не и с подхода за сляп подпис, който обикновено изисква използването на фиксирани суми.
Обсъдихме Скриването на суми чрез Pedersen ангажименти в предишна седмични новини.
Фиксирани деноминации
Фиксираните деноминации са друга форма на защита на поверителността, подобна по функции на Скриването на сума. Само определен ограничен брой суми са разрешени от системата. За да представи всяка друга сума, човек трябва да направи промяна, като използва известните суми.
Принуждаването на всички транзакции да използват тези фиксирани суми означава, че всички входове и изходи за транзакция изглеждат редовни. Въпреки че общата сума на дадена транзакция е видима, човек не може да проследи ефективно даден вход или продукция по нейната сума, защото тя се слива в океан от други монети на стойност същата сума. Като такива, всички единици от дадена сума са взаимозаменяеми.
Ето защо е важно общият брой на сумите да се поддържа малък. Човек би могъл например да дефинира всяка цяло число към неговата собствена сума. Въпреки че това ще работи технически, то е лошо за поверителността, тъй като хората често използват много уникални суми. Вместо да се слее в океан, една капка се скита сама.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България