Existing Structs (All remain unchanged) // ------ Within bls_signature_aggreator crate ------ pub struct Proof { pub public_key: bls::PublicKey, pub signature: bls::Signature, } // --------- Within routing crate -------------------

This document describes in detail how churn (nodes joining and leaving the network) is handled in routing. Glossary Address See Name. Agreement Any action that affect the section must be agreed on by a supermajority (> 2/3) of the section elders. This is implemented by the section elders proposing the action by creating a message containing the proposal and signing it with their BLS secret key share. They then broadcast the signed proposal to the rest of the elders. Elders then aggregate the signature shares of these proposal and once they receive enough of the shares (> 2/3), they combine them into a full BLS signature which together with the corresponding public key form an undeniable and independently verifiable cryptographic proof of the action and they can the perform it. ELDER_SIZE

As an expanded explaination of SectionChain based on Adam's writeup at Section chain and proof chain. pub struct SectionChain { root: bls::PublicKey, tree: Vec<Block>, } struct Block { key: bls::PublicKey, signature: bls::Signature,

This document is aiming to illustrate the thoughts of section key chain handling during the situation of too many elders within one section dropped at the same time. Under such situation, a concensus within a section cannot be maintained any more, under the current algorithms, as no more enough number of provable existing elders to pass down the concensus status to new elected elders via majority votes. Before going further into the detailed description of the handling thoughts, there are some concepts worth to be clarified or defined first. What is the Section Key Chain here Every node within the safe network will have a ED25519 keypair, whose public key actually becomes that node's name. Other nodes can use that public key to verify the signatures that node signed with its private key. For the convenience, we use Key_ED(x) to stand for such key pair for node x. Meanwhile, when a node behaves as an elder for a Section(pfx) (a section with a prefix of pfx), it will also maintain a bls_keyshare and bls_publickey, as a result of a DKG process (here is a high level explaination of DKG process used for safe network). The bls_publickey is known to public, and can be used to verify the signature_shares signed by correspondent bls_keyshares. Note that each elder has its own bls_keyshare, meanwhile bls_publickey is the same among the elders paticipated for this round.

sn_routing internal components and execution flow Notes: The Comm component is not included in the diagram for simplicity, and messages are shown as sent directly to qp2p in the diagram. The Stage component has read-only access to the SectionInfo. This shall give us higher concurrency/throughput for processing messages. The SectionInfo is a wrapper exposing APIs for reading states and applying operations from/to EldersBftCrdt, AdultsBftCrdt, and KeyChainBftCrdtBFT-CRDT containers. participant qp2p participant Executor as exec #lightblue

Nothing is all figured out here. This is a brainstorming document, intended to layout the current files API landscape and explore how things could evolve. Here's a slack discussion, with some background. See also: Survey of RUST/FUSE FileSystem Libraries. Current Situation Presently, the safe-api exposes the concept of a FilesContainer, which consists of a BTreeMap where the keys represent file paths and the values represent metadata. The metadata is another BTreeMap of key/val pairs. The FileContainer gets serialized to JSON in its entirety and stored on the network as one version of a PublicSequence. Changes and Reads of any path require [de-]serializing the entire directory structure, and filtering or re-writing it. This becomes expensive for large tree structures.

We are looking for a library or set of libraries that would enable us to have a single SAFE Network FileSystem codebase that operates on both unix and windows platforms. With that in mind, we list some options below: Library/Crate Platform(s) Rust? Stable? Notes

See here for background. Implementing filename conflict resolution A problem arises: Quoting again from the paper: In practice, the collision would be resolved by making the filenames distinct, eg by appending a replica identifier to the filenames. However, using the Tree data structure as specified in the paper (and my code), I did not see an obvious way to append a replica ID to both conflicting entries while applying a remote op to local state.

I received a copy of this dissertation and the author was kind enough to send code as well. note: I have agreed not to share either publicly, but can share the paper with the development team. I am also not disclosing the author's name publicly without permission. Team members can find the paper here. The author has implemented a distributed filesystem (in Rust!) that implements the crdt-tree algorithm and mounts via FUSE. I have read the paper in great detail and have also built, run, and briefly reviewed the code.

###### tags: `admin` # Public team space Where we can not look silly and be crazy with ideas