Някой в настроение за по-дълбоко гмуркане?
Преди няколко седмици @oetyng ни даде актуална информация за дизайна на разплащателната мрежа и как тя може да функционира самостоятелно.
Тъй като технологичният стек на мрежата сега се движи с темпове, които не можехме да предвидим дори преди две седмици, си дадохме свободата и гъвкавостта да преследваме различни пътища за стартиране, независимо дали става дума за мрежа само за плащания или директно за пълната мрежа за данни от самото начало.
Така че @oetyng преразглежда света на плащанията, за да обясни как се интегрира със съхранение, портфейли и клиентски API-та в новия опростен дизайн.
Първо, няколко думи за това как се оформя мрежата, докато преминаваме от дизайна със секции към дизайн с Kademlia. Kademlia изисква възлите да говорят помежду си в цялата мрежа, а не само с тези в техните секции. Ако не го правят, таблицата за маршрутизиране скоро ще стане остаряла и пълна с мъртви възли и мрежата ще умре от погрешна комуникация. Проверката на DBC първоизточниците е начин постоянно да се гарантира, че възлите са активни, като същевременно изпълняват жизненоважна функция, така че можем да се възползваме от това там.
Транзакциите ще се извършват много бързо в мрежата, но Safe не е база данни и не е подходящ за бързи мутации на данни. Този тип работа се извършва от страна на клиента, като резултатите след това се съхраняват/репликират в Safe. CRDT означава, че клиентите могат да си сътрудничат ефективно, в реално време и без конфликти, а резултатите от тези сътрудничества могат да се съхраняват публично или частно в Safe. Преместването в Кадемлия изяснява това разделение на труда.
Друг резултат от промяната е, че малките тестови мрежи е малко вероятно да бъдат стабилни. Новият дизайн вероятно ще се нуждае от 2000 или повече възли, за да функционира правилно. Това изобщо не е проблем, но очевидно ще промени начина, по който управляваме тестовите мрежи.
Общ напредък
Докато вървим към възможността да пуснем нещо за обществено тестване, Джим работи върху позиционирането, пътните карти и съобщенията. Разгледайте неговата тема Какво е стартирането, ако още не сте го направили.
С наближаването на този ден @bzee рови в NAT traversal и как можем да го внедрим, а @bochaco подготвя нашите типове данни за интегриране в новата мрежова инфраструктура, включително работа върху API-то, за да позволи на разработчиците да започнат със създаването на приложения възможно най-скоро тъй като ще имаме нещо стабилно. Bochaco също разглежда съобщенията за грешки, за да види къде можем да ги направим по-конкретни и полезни.
Другата голяма част от работата е сортирането на близките групи. Като се има предвид името на част от данните (същото като неговия XOR адрес), клиентът знае кои k възли да поиска, за да ги извлече, но трябва ли да започнем с 20 или 8? Повече означава, че повече възли актуализират своите таблици за маршрутизиране, но това е и повече съобщения. А когато съхраняваме DBC? Това е нещо, с което @roland и @qi_ma се занимават. @roland също преразглежда репликацията на данни.
Разбира се, трябва да можем да видим какво се случва и @Chriso преработи внедряването на OpenSearch в хранилището на тестовата мрежа, за да направи път за настройката за наблюдение.
И @oetying започва да обединява всички тези неща заедно. Още от него по-долу!
DBC, трансфери и портфейли
Опростяване на DBC кода
През последните няколко седмици DBC кодът претърпя дълго очаквано и необходимо опростяване. Имаше както повече документация, така и малък основен ремонт на терминологията, съгласуване на именуването и концепциите за по-малко когнитивно натоварване.
Друго нещо, което можехме да направим сега, тъй като вече нямаме секции и Старейшини, беше да премахнем мрежовото подписване на DBC. Това само по себе си е огромно опростяване. Това, което имаме сега, е, че трансферът може да бъде изграден напълно офлайн и всичко, което трябва да направите, е да изпратите частите от DBC, наречени подписани разходи (това означава ключът, съответстващ на DBC id, подписаните разходите на това DBC - така че подателят на токените е подписал изразходването). Когато достатъчно партньори в мрежата са приели тези подписани разходи, транзакцията е завършена и валидна.
Харчене на DBC в мрежата (трансфери или плащания за данни)
И така, да се отдръпнем малко.
Вместо да искаме от Старейшините на дадена секция да потвърдят и подпишат разходи (т.е. трансфер или плащане за данни), както се правеше преди, сега изпращаме подписани от клиента разходи до близката група на идентификатора на DBC за харчене. (Ние го наричаме адрес. Така че парчетата имат адрес, регистрите имат адрес и DBC разходите имат адрес). Тази близка група е споменаваба и преди. Връстниците от близката група не подписват нищо. Те просто валидират изразходваното, като всеки от тях действа независимо, и го съхраняват, ако го намерят за валидно. Част от намирането му за валидно е да се потърсят родителите на конкретния разход. Това означава да се търсят разходите, които са довели до създаването на точно този DBC, който сега се изразходва.
Ако тези родителски разходи могат да бъдат извлечени от съответната им близка група, това означава, че те са валидни, тъй като самите те са преминали през този процес, когато са били изразходвани.
Разбира се, има повече валидации, като заслепените суми, които се проверяват за входове и изходи, които ключовете на входните dbc са подписали правилно и т.н.
И когато всичко това е потвърдено като валидно, възела просто съхранява тези подписани разходи. И когато клиент трябва да провери дали DBC, който е получил, е валиден, той просто иска от мрежата да върне подписаните разходи, довели до създаването на този DBC. Ако необходимия брой възли го връща, значи е факт.
Близки групи
И така, близките групи. Не забравяйте, че те се намират по близост до идентификатора на DBC (или хеша на данните). Те могат да бъдат 4, 8, 16 възли или повече. Ще започнем с определено число и ще променяме, докато напредваме. Но има нещо повече. Можем да добавим слоеве чрез хеширане на id/името и да получим нов адрес, който е детерминистично извлечен от първия. Сега можем да съхраняваме същия елемент и в тази група. И така може да продължим, хеширане на този адрес отново, и отново, и за всеки път има още една група, която държи елемента.
Това са някои от лостовете, които бяха споменати преди. Ще започнем просто с една група, защото първо искаме да стартираме и да работим в тестова мрежа.
Портфейли
Току-що завършихме първото просто внедряване на портфейл, който съдържа DBC и история на транзакциите. Както при данните, първата версия използва съхранение в паметта. След това ще го съхрани локално на устройството, а след това ще направим мрежово съхранение. Хубавото е, че внедряваме портфейла, за да има прост интерфейс, който може да се използва с всеки от трите (или всички) от гореспоменатите носители за съхранение.
Това, което също беше взето под внимание този път, е, че всички възли ще трябва да имат портфейл за своите награди. Но все още не сме съвсем там, още седмица или две за това. (И да, сега е много по-лесно да се правят оценки за времето.)
Такси за прехвърляне
Те бяха описани съвсем наскоро в седмичните новини и там нямаме много промени. Плащанията отиват към възли и опашката с приоритети (преди наричана mempool) е същата.
Това, което вероятно ще разгледаме скоро, е как същият модел може да се приложи за плащания за данни.
И това е всичко относно напредъка по преводите и плащанията засега.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България