Safe Network новини 🇧🇬 13.10.2022

Новини
1

1
1830×430 391 KB

От известно време говорим за преработения процес за избиране на нови Старейшини на секции и управление на разделения. Тази седмица @anselme ни превежда през мисловния ни процес зад него.

Общ напредък

@Chriso преработва процесите за подписване на парчета данни и регистри, и тества съхранението и предпазването от двойно изразходване на DBC.

@roland разработва тестове за sn_sdkg AE и функционалността за членство, описани по-долу.

Мостафа проучва децентрализирани механизми за консенсус и преразглежда текущото ни положение.

@davidrusu преработва процеса на присъединяване, за да включи актуализиране на знанията за мрежата преди присъединяването.

А @anselme и @dirvine преработват процеса на пълномощия, както описахме миналата седмица.

@bzee, @bochaco и @joshuef работят върху отстраняването на грешки в стабилността на по-ниско ниво. Виждаме комбинация от бавно обработване на съобщения и грешки в управлението на връзката, които понякога причиняват проблеми. Така че правим дълбоко проучване тук. Постигнахме известен напредък, опростявайки начина, по който се обработват съобщенията и продължаваме на този фронт, тъй като изглежда, че ще бъде доста обещаващо преструктуриране, както по отношение на простотата на кода, така и по отношение на стабилността.

Всичко за sn_sdkg

DKG с sn_sdkg

  • Въз основа на генерирането на poanetwork ключ в hbbft
  • Премахва таймерите
  • Въвежда Gossip
  • Обхваща едновременни DKG
  • Състезание между различните DKG до Handover

Току-що интегрирахме sn_sdkg (генериране на синхронен разпределен ключ за Safe мрежата), заменяйки предишната версия, в която видяхме грешки и изчакване, когато мрежите бяха бавни. Основната причина вероятно е, че използвахме таймери. Този нов DKG процес не използва таймери, всъщност ние изобщо не искаме никакви таймери в Safe, никъде.

DKG не е активен, това е просто нещо, което възлите правят във фонов режим, когато получават системни съобщения, и могат да изпълняват множество сесии едновременно.

Освен че използва анти-ентропия (AE), sn_sdkg въвежда и клюки, за да се увери, че възлите получават всички съобщения, които може да липсват, така че в крайна сметка всички да са последователни.

Нека го разгледаме:

Старейшините изпращат DkgStart

  • разделяне на секция
  • предаване на секция

Първата стъпка в процеса е Старейшините да изпратят съобщение DkgStart. Това се случва, когато възникне една от две ситуации. Първата е, когато възел пристигне в секция и е по-стар от един или повече от текущите Старейшини. В този случай трябва да извършим предаване - новият възел се повишава и знанията за секцията се предават. Вторият сценарий е, когато секцията стане твърде голяма и се раздели.

pub struct DkgSessionId {
    /// Prefix of the session we are elder candidates for
    pub prefix: Prefix,
    /// Other Elders in this dkg session
    pub elders: BTreeMap<XorName, SocketAddr>,
    /// The length of the section chain main branch.
    pub section_chain_len: u64,
    /// The bootstrap members for the next Membership instance.
    pub bootstrap_members: BTreeSet<NodeState>,
    /// The membership generation this SAP was instantiated at
    pub membership_gen: Generation,
}

Когато има събитие „DkgStart“, Старейшините генерират информация в структура, наречена „DkgSessionId“ (форматът се нарича „структура“ в Rust). Те подписват тази структура със своя дял от BLS ключове и я обменят с другите Старейшини. Всеки DkgSessionId предоставя основна информация за текущото състояние на нещата и е уникален за дадения DKG кръг.

Префиксът е префиксът на текущата секция. В случай на предаване не се променя. В случай на разделяне го прави и ние добавяме единица или нула към текущия ни префикс в зависимост дали сме от страната 0 или 1 на разделянето.

Полето elders съдържа всички нови кандидат-Старейшини за тази DKG сесия, възли с възраст на възел, равна или по-голяма от тази на текущия Старейшина.

section_chain_length (за преименуване) е разстоянието от текущия ключ на секция обратно до Началото (Genesis). Можем да мислим за това като за „генериране на секции“.

membership_gen също показва генерирането на членство. Различава се от генерирането на секции. Всеки раздел има много поколения членство и дължината на веригата не се променя.

bootstrap_members са текущите Старейшини в секцията.

След като възлите получат DkgSessionId от всички текущи Старейшини, те могат да започнат DKG сесия.

Да започваме!

Dkg стъпки

flowchart LR;
A[DkgStart] --> B[Ephemeral Key]

Всички настоящи и кандидат-Старейшини получават съобщение „DkgStart“, което е адресирано до тях и в което те са включени като elders в структурата „DkgSessionId“.

След това всеки от тези възли генерира ефимерен еднократен BLS ключ, който се използва само за този DKG кръг. Този ефимерен ключ е подписан с техния ключ ed25519, който служи за тяхната самоличност, така че другите възли могат да проверят дали е валиден.

Dkg стъпки

flowchart LR;
A[DkgStart] --> B[Ephemeral Key] --> C[Voting]

Следва етапът на гласуване, в който всеки възел може да генерира свои собствени ключове за гласуване. Използваме процес, заимстван от генерирането на ключ на Poanetwork в hbbft, който гарантира, че всеки възел може да генерира само свой собствен ключ и не използва информация от други възли за генериране на отделен ключ за DKG кръга.

Възлите гласуват кой от кандидатите и съществуващите Старейшини сега трябва да бъдат избрани за Старейшини на секциите.

Dkg стъпки

flowchart LR;
A[DkgStart] --> B[Ephemeral Key] --> C[Voting] --> D{Key Generation}

След като гласуването приключи, кандидатът генерира нов ключ, който изпраща на настоящите Старейшини, за да докаже, че отговаря на условията да стане Старейшина (тъй като супермнозинството възли са го подписали с новоизсечения ключ). Така че DKG е нещо като тест за добър кандидат. Ако не завършат DKG, те не са достатъчно добри.

Паралелност

flowchart LR;
A[DkgStart1] --> B[Ephemeral Key] --> C[Voting] --> D{Key1 Generation}

flowchart LR;
A[DkgStart2] --> B[Ephemeral Key] --> C[Voting] --> D{Key2 Generation}

Могат да се провеждат няколко DKG сесии наведнъж. Всеки път, когато има нов член в секцията, може (ако новият възел е по-стар от който и да е от текущите Старейшини) да имаме нова DKG сесия, така че ако докато една сесия продължава, нов възел се присъедини, може да започне друга DKG сесия. Някои ще прекратят, други просто ще прекъснат и ще се провалят. Това е състезание и ние избираме първия, който завърши. По-късно, ако се окаже, че има по-стар възел, който не е Старейшина, процесът започва отново.

Разрешено чрез предаване

stateDiagram-v2
Dkg1 --> Handover
Handover --> Winner:Dkg1
Dkg2 --> Handover
Dkg3 --> Handover

Ако има равенство, искаме само един победител, т.е. един нов Старейшина. Предаването е процес, който използва консенсус, за да реши кой трябва да спечели.

Активен AE

stateDiagram-v2
DkgStart --> EphemeralKey
EphemeralKey --> EphemeralKey: Includes DkgStart AE
EphemeralKey --> Voting
Voting --> Voting:Includes EphemeralKeys AE
Voting --> Termination

В тези етапи, споменати по-горе, получаване на DkgStart съобщение, създаване на ефимерен ключ и гласуване, трябва да компенсираме мрежовите проблеми и бавните възли. Например, имаме нужда от ключовете на всички, за да започнем да гласуваме, ако не, засядаме. Така че ние включваме AE във всяко съобщение, свързано с ключ, за да предоставим информация, че даден възел може да липсва. AE е лек и ефективен начин да се уверите, че всички възли работят на ниво.

enum SystemMsg {

    DkgStart(DkgSessionId),

    DkgEphemeralPubKey {
        /// The identifier of the DKG session this message is for.
        session_id: DkgSessionId,
        /// Section authority for the DKG start message
        section_auth: AuthorityProof<SectionAuthProof>,
        /// The ephemeral bls key chosen by candidate
        pub_key: BlsPublicKey,
        /// The ed25519 signature of the candidate
        sig: Signature,
    },

    DkgVotes {
        /// The identifier of the DKG session this message is for.
        session_id: DkgSessionId,
        /// The ephemeral bls public keys used for this Dkg round
        pub_keys: BTreeMap<XorName, (BlsPublicKey, Signature)>,
        /// The DKG message.
        votes: Vec<DkgSignedVote>,
    },

    DkgAE(DkgSessionId),

    ...
}

В кода Системно Съобщение, което е типът съобщение, използвано за процеси, които могат да променят структурата на мрежата, изглежда като горното. Това капсулира всички процеси, за които говорихме.

Устойчивост

  • Активен AE
  • Гласуване AE
  • Клюка
    • когато чакате гласове
    • при получаване на остарели гласове

За да приключим, имаме множество механизми за устойчивост при обработка на предавания и разделяния.

Активен AE означава, че на възлите се изпраща информация от предишната стъпка, в случай че са я пропуснали.

Имаме и клюки като резервен вариант. Ако сте в DKG сесия, вие сте готови да получите ефимерни ключове или гласове от някого. Ако те не се появят, изпращате текущите си знания на другите с надеждата, че те ще ви актуализират. Освен това, ако получите остарял AE от някого, можете да го актуализирате.

Така че клюките имат две цели. За да сме сигурни, че сме актуални, за да можем да продължим напред, и за да актуализираме другите, за да можем да стигнем до прекратяване.

Заедно с AE и позволявайки конкуренция между процесите на DKG, това осигурява много по-стабилен процес за насърчаване на нови старейшини и справяне с разделения. По време на разделянето имаме две DKG, а не една.

Преводи:

:uk: English :ru: Russian ; :de: German ; :es: Spanish ; :fr: French

  • Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България