Повече от всичко друго, нещото, което затруднява надеждното децентрализиране при разпределените мрежи, е асинхронността: просто не можем да гарантираме, че „съобщение A“ ще пристигне преди „Съобщение Б“ или дори ако изобщо ще пристигне. С няколко възела това е добре, но в раздел с десетки възли броят на възможните комбинации от събития и съобщения е огромен и истинско предизвикателство за разсъждение. Тази седмица разглеждаме Stateright, много полезен инструмент за тестване на нашите алгоритмични предположения, тъй като той опитва всички различни възможности.
Общ напредък
@Bochaco тества отговора на мрежата на различни размери на парчетата, включително как обработва картите на данните. Малките парчета са по-бързи за предаване, но те правят много по-големи карти на данни, така че трябва да ги само-криптират рекурсивно, докато не са по-малки от chunk_size. Има и други доста технически компромиси, но по принцип търсим оптимален размер за нашите парчета.
@Anselme и @dirvine разглеждат поле “причина” в DBC SpentProofs - доказателството за транзакция. Това е ново поле, което съдържа причината за разходите. То може да бъде хеш на парчета, платени или номер на поръчка за покупка, или някакъв друг вид етикет. Важното е, че Старейшините ще могат да разберат дали е валиден или не (например, ако е плащане за едно парче, транзакцията съвпада ли с цената на съхранение на данните?).
Защо да правим това? Опростяване и сигурност. Това може да ни позволи да премахнем нуждата от Старейшините да подписват данни. Така че, няма повече риск от "атака със стари ключове“, когато ако лош актьори получат предишен ключ, те биха могли да го използват за валидиране на данни. С този дизайн подписите на предишните Старейшини вече няма да са валидни.
Как се случват нещата:
- Клиентът иска да получи цена за съхраняване на данни: 1 SNT, моля
- Клиентът преиздава 1 SNT DBC за Старейшините с препратка към данните като DBC причина
- Клиентът казва на Старейшините, че се изразходва чрез изпращане на записа в SpentBook за този DBC (записите съдържат „причина“)
- Старейшините проверяват тази причина и актуализират своите SpentBook
- DBC вече е официално изразходван по причина
- Клиентът пита текущите Старейшини за подписано копие на този запис в SpentBook
- След като клиентът получи достатъчно подписи, той може да изпрати данните, като предостави текущо подписано копие на записа на SpentBook заедно с данните
- Старейшините проверяват дали подписаният от секцията (което означава, че повечето Старейшини виждат една и съща причина) запис в SpentBook се отнася до данните и ги съхранява.
Продължаваме да премахваме проблеми с четене/запис за по-добра производителност и опростяване (без многопоточна обработка, освен ако не е абсолютно необходимо). @joshuef работи за премахване на един голям проблем около самия node.
Някои членове на общността с остри очи вече забелязаха @oetyng да моделира опростена версия на платежна мрежа.
@Chriso работи върху подобряването на аспектите на CLI, включително преработката на командата за актуализиране.
А @davidrusu работи усилено върху Stateright.
Stateright
Stateright е Rust библиотека, която обещава да бъде голяма помощ при тестването на предположения. По принцип това е проверка на модела, който преминава през всяка възможна комбинация от събития, за да провери дали заявеното предположение е валидно.
Децентрализираните мрежи са трудни за моделиране по различни причини: възлите могат да умрат, възлите могат да бъдат злонамерени, съобщенията могат да се забавят, съобщенията могат да пристигнат извън ред или изобщо да не пристигнат, можете да получите неочаквани условия на състезание и т.н. и т.н. Stateright ни помага да преминем през всички тези възможности.
Като пример може да искаме да знаем дали двойното харчене на DBC е възможно с настоящия ни дизайн. Ние моделираме предположението „Двойно харчене не е възможно“ в кода, добавяме това към съществуващата ни кодова база и пускаме Stateright през него. След това Stateright ще преминава през всяка една комбинация, както е разрешено в нашия алгоритъм модел. Той ще забави съобщенията, ще накара два Старейшина да се провалят наведнъж и да изпращат събития извън ред. След като изчерпа всяка възможност, без да можем да предизвика двойно харчене, получаваме хубава зелена отметка - нашето предположение е валидно. Всяко състояние, което намери, беше успешно.
Ако нещо се провали, по желание ни пренасочва към GUI, където можем да преминем през съобщенията, довели до провал и да разберем какъв е проблемът.
Страхотното е, че се опитва всичко, а не само подмножество от възможни комбинации. В децентрализираните мрежи това са крайните случаи, които ви убиват, а със Stateright, за разлика от други методи, които използват вземане на проби, можете да сте сигурни, че сте ги обхванали всичките. Може да има милиони комбинации, които да преминат, но стига да сме написали правилно предположенията, това става доста бързо.
Другото е, че това е голяма помощ при итеративното коригиране на нашия код. Това са няколко допълнителни функции, които можем да поставим в нашата кодова база в продукция, за да проверим моделите. Най-вероятно ще използваме това, за да напишем конкретни кодове в продукция и да го направим в модел. Когато моделът е удовлетворен, ние приемаме този код и го добавяме в Safe.
Можете да разберете повече за Stateright в DOCS или от това видео - което, въпреки че е интро, е доста техническо.
Още по-добре, ето ви връзка към настоящите ни експерименти. Ако сте любопитни просто клонирайте това хранилище github-maidsafe/stableset-experiments. Използваме главния клон от Stateright, така че ще трябва да го клонирате и в същата папка, където сте клонирали експерименталното хранилище.
Бъдете наясно, обаче, че това са експериментални данни от Safe Labs в реални условия и се променят значително ден за ден, тъй като ние увеличаваме усилията в нашите търсения към опростяване.
Ако използвате командата cargo run --release и след това отворете http://127.0.0.1:3000, ще видите GUI. След това можете ръчно да щракнете върху какви съобщения да изпратите или директно кликнете върху „стартиране до завършване“ и това ще ви покаже къде са всички текущи проблеми. Бъдете наясно, че почти винаги имаме проблеми там, тъй като итеративно тестваме, така че не се чувствайте обезсърчени, всъщност е страхотно 
.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България