Само бърз отчет за напредъка тази седмица, тъй като отново работим по много фронтове, без основен нов инструмент, разработка или идея за докладване.
Благодарим за коментарите относно мрежата насочена само към разплащания. Оценяваме това внимателно от техническа гледна точка, но и стратегически. Изисква се тясна координация с нашия правен екип, така че ще ви държим в течение с напредването на дискусиите.
Тествахме архитектурата на стабилния набор, използвайки stateright и досега всичко е добре 
. Моделирахме едновременната загуба на всичките седем Старейшини и последващото повишение на седем Възрастни от стабилния набор. „Stateright“ отнема доста време, за да премине през около 160-те милиона възможни състояние, но нито един от тях не завърши с разцепване на мрежата, което е много обнадеждаващо. Все още обаче не сме спокойни, защото докато членството изглежда солидно, функционалността, изградена върху него, може да не е. Така че това е следващата стъпка.
@Oetyng използва този период между основните преработки, за да извърши пролетно почистване и преструктуриране. Едно от нещата, върху които работи е интегрирането на ключовете за награди в sn_node. Използваните преди това ключове за награди ed2559, които бяха съхранени в ~/.safe, не могат да се използват с DBC, каквито са сега. Така че ги актуализирахме до BLS ключове и ги добавихме към информацията за възела и - което е важно - към структурата, която се гласува в членството. Старейшините трябва да знаят ключа за възнаграждение на възел, така че да могат да валидират входящите плащания и да проверят дали разходите за прехвърляне/съхраняване са изплатени на възлите.
Следващите задачи са:
- Старейшините се включват в резултатите при изразходване на DBC.
- Старейшините потвърждават, че разходите съдържат резултати, предназначени за тях.
- Прилагане на общоизвестни детерминирани разходи за прехвърляне/съхранение и разпределение до възли.
- Включително разходи за прехвърляне/съхраняване в изходи при изразходване на DBC.
- Старейшините потвърждават, че сумите в тези резултати са достатъчни.
Той също така премахна двусмислената концепция „peer“, където клиентите и възлите се третираха еднакво за целите на съобщенията, създавайки по-ясен път за клиента и логиката свързана с възела. Това беше дългоочаквана промяна и с интегрирането на ключ за награда използването му като част от възел има много повече смисъл.
Също така върху DBCs работи и @anselme, който отново разглежда плащанията сега, след като по-ранният дизайн на RingCT е отхвърлен. Голяма част от предишния код за плащания трябва да може да се използва и той го преглежда в момента.
@roland завърши курс по OpenSearch - платформата, която използваме за телеметрия.
Все още виждаме бъгове, когато възлите не успяват да се присъединят, и @qi_ma работи по тях.
Мостафа прецизно настройва алгоритъма за консенсус, за да гарантира, че всички предложения са придружени от подкрепящи доказателства.
@Chriso продължава да опростява CLI-то и да премахва обвивки и неизползвани или безполезни команди. Сега е моментът да кажете, ако има нещо, което искате да видите в CLI. Моля, използвайте тази тема за предложения.
И не на последно място @bochaco надгражда Quinn и всички зависимости на qJSON-RPC. Той също така разглежда gRPC, рамката за извикване на отдалечени процедури, първоначално създадена от Google, тъй като изглежда неизбежно нещата да вървят по този начин с поддръжката за HTTP/3 и Quic. Предлага много предимства пред qJSON-RPC.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България