Накратко
- qp2p получи вниманието ни тази седмица, като направихме подобрения в производителността, особено около басейна за връзки.
- Създаването на множество копия на парчетата данни се въвежда отново в кода.
- С радост чухме за скорошна академична статия от авторите на AT2, озаглавена Динамично византийско надеждно излъчване, която изглежда предоставя официално доказано решение точно по нашия проблем.
- При sn_routing сме в процес на добавяне на join_flag, за да установяваме дали да приемаме нови възли в мрежата или не.
Safe клиент, възли и qp2p
Safe Network трансфери план на проекта
Safe клиент план на проекта
Safe Network възли план на проекта
Първо, тази седмица внедрихме обединяване на връзки в qp2p. Това означава, че ако възел иска да се свърже с връстник и връзката е била отворена преди (и все още е отворена), ще използваме съществуващата връзка, вместо да изграждаме нова. Това подобрява производителността, тъй като изграждането на връзка е скъпо (това включва TLS ръкостискане, наред с други неща). Това също подобрява ергономичността, тъй като потребителите на qp2p вече не трябва да се притесняват от кеширането на връзката. Също така внедрихме дедупликация на връзката, което означава, че множество едновременни опити за свързване към един и същ възел ще се осъществят през една връзка, вместо да отварят отделна връзка за всеки опит. Това отново подобрява производителността.
Връщаме се към създаването на копия на парчетата от Blob данни в sn_node. Започвайки с коефициент от 4 копия, възрастните в мрежата ще носят главна отговорност за тяхното съхраняване. Пренасяме по-старата реализация от предварителни асинхронни хранилища към новата кодова база, като я адаптираме към най-новите промени в съхранението, заявките и т.н. Тази седмица също правим известно разчистване навсякъде, като преследваме основно проблеми с разгъване, очакване и паника от производствения ни код и тестове, като по същество стабилизират кодовата ни база и улавят всички изключения. Това е най-добрата практика и нещо, което отлагаме твърде дълго. Очаквайте допълнителни проверки на CI, които да бъдат добавени през следващите няколко дни в контейнерите ни, за да гарантират, че те няма да се появят обратно в кода.
Инвестирахме малко време в проучване и обмисляне на това как API-тата в крайна сметка ще трябва да се развият, за да поддържат искания за подписване от клиента, използвайки множество двойки ключове, а не само една. Например, клиент може да поиска да съхранява файл, който би бил собственост на публичен ключ, докато плащането за такава операция ще се извършва с помощта на втори публичен ключ, който притежава средствата, а може би трети публичен ключ може да бъде използвана от клиента за криптиране на съдържанието на файла. В момента това не е нещо, което обмисляме като приоритет, по-скоро като доказателство на концепцията, което да ни помогне да идентифицираме предизвикателствата и да осъзнаем как в крайна сметка да развием нашите клиентски API-та.
CRDT
Продължава работата по динамичното членство в DSB и тази седмица консултантът е написал тестов случай, който демонстрира проблем с паралелността при операциите с данни, когато член напуска групата. Правилното изпълнение на динамичното членство винаги трябва да преминава теста, докато настоящото ни наивно изпълнение се проваля, така че сега имаме нещо конкретно, с което да го измерим.
За тази цел сме развълнувани от скорошната академична статия от авторите на AT2, озаглавена Динамично византийско надеждно излъчване. Тя ще ни предостави: „първата спецификация на динамично византийско надеждно излъчване (dbrb) примитив, който е подходящ за асинхронно изпълнение“. С други думи, тази статия предлага официално доказано решение за точно нашия проблем.
Понастоящем консултантът прави преглед на тази статия, както и на друго възможно решение, използващо нещо, наречено Часовник за генериране, което може да не изисква толкова много мрежова комуникация.
Маршрутизиране
Както бе споменато в новините от миналата седмица, работата за разрешаване на възел да се присъедини със същото име беше одобрена и обединена тази седмица. Това означава, че всеки свързващ се възел ще бъде незабавно преместен с половината от възрастта си, стига половината възраст да е по-голяма от MIN_AGE (в момента 4). Това е предназначено да предотврати злонамереното рестартиране.
По време на вътрешното тестване забелязахме, че първоначалния (генезис) възелът понякога се понижава твърде бързо, това е вследствие на скорошна промяна, при която правим възлите с произволен диапазон от възрасти по време на фазата на стартиране. За да разрешим това, решихме да стартираме първия възел с по-висока възраст, понастоящем зададен на 32. Това вече е добавено в кода. Така гарантираме, че генезисният възел остава стабилен като старейшина за достатъчно дълго време, което улеснява много неща за тестване и настройка на тестови мрежи.
Продължаващата работа за подобряване на откриването на загубена връзка между възлите напредва добре. Вече се възползвахме от новата функция за обединяване на връзки в qp2p, която ни позволи да опростим кода. Някои първоначални тестове за интеграция показват, че преструктурирането работи добре. Този PR сега преминава през последен преглед и тестване и затова се надяваме скоро да бъде обединен.
За да гарантираме, че когато ресурсите на възела са близо до изчерпване, ще има нови възли, които да се вливат, за да споделят натоварването, ще позволим на възлите да казват на маршрутизиращия слой да приема нови възли или не. Това ограничение за това кога мрежата приема нови възли също ще помогне за предотвратяване на Сибил атаки, като не позволява на потенциалните нападатели да добавят неограничени възли по свое желание.
В допълнение към това, също така се стремим да направим някои промени, които да ни помогнат да се информираме за точното състояние на маршрутизацията по време на стартиране на мрежата и след това, с тази цел имаме две текущи PR - Индикация за стартиране на секция и задействане на PromotedToAdult събитие и уведомяване при промяна на ключа по време на преместването. Тези промени са в ход и ще ни помогнат да гарантираме, че маршрутизацията се държи по коректно и трябва да бъдат завършени скоро, след като API дизайна им е съгласуван между възлите и маршрутизацията.
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България