14 unstable releases (4 breaking)

0.6.0 Mar 28, 2024
0.3.0 Sep 21, 2023
0.2.6 Jun 29, 2023
0.2.5 Mar 16, 2023
0.2.0 Jul 26, 2022

#1677 in Magic Beans

Download history 46/week @ 2023-12-28 13/week @ 2024-01-04 3/week @ 2024-02-15 10/week @ 2024-02-22 244/week @ 2024-02-29 29/week @ 2024-03-07 2/week @ 2024-03-14 161/week @ 2024-03-28 13/week @ 2024-04-04

179 downloads per month
Used in 2 crates

GPL-3.0 license

485KB
10K SLoC

Rings Network

Rings Core

rings-node cargo docs

Architecture

The Rings Network architecture is streamlined into five distinct layers.

Runtime Layer

The design goal of Rings Network is to enable nodes to run in any environment, including browsers, mobile devices, Linux, Mac, Windows, etc. To achieve this, we have adopted a cross platform compile approach to build the code. For non-browser environments, we use pure Rust implementation that is independent of any system APIs, making our native implementation system agnostic. For browser environments, we compile the pure Rust implementation to WebAssembly (Wasm) and use web-sys, js-sys, and wasm-bindgen to glue it together, making our nodes fully functional in the browser.

Transport Layer

The transport layer of Rings Network is based on WebRTC protocol, which provides browsers and mobile apps with real-time communication capabilities through simple interface.

The WebRTC protocol obtains the optimal connection path between nodes by exchanging SDP (Session Description Protocol), which can be either TCP or UDP. In the Rings Network, we use WebRTC's data channel to implement data communication. For a typical ICE (Interactive Connectivity Establishment) process, it can be described as follows:

Assuming Node A and Node B want to create a WebRTC connection, they would need to exchange a minimum of three messages with each other:

ICE Scheme:

  1. Peer A: { create offer, set it as local description } -> Send Offer to Peer B
  2. Peer B: { set receiveed offer as remote description create answer set it as local description Send Answer to Peer A }
  3. Peer A: { Set receiveed answer as remote description }

For native implementation, the transport layer is based on webrtc.rs, and for browser case, we implemented based on web_sys and wasm_bindgen.

To check the implementation of transport layer: https://github.com/RingsNetwork/rings-node/tree/master/transport

Network Layer

The network layer is the core component of the Rings Network, responsible for DID (Decentralized Identifier) discovery and services routing within the network. The Rings Network employs the Chord DHT (Distributed Hash Table) algorithm as the implementation for its network layer.

The Chord algorithm is a well-known DHT algorithm characterized by its formation of an abstract circular topology structure among all participating nodes. It has a lookup algorithm complexity of O(log(N)).

Protocol Layer

In the protocol layer, the central design concept revolves around the utilization of a Decentralized Identifier (DID), which constitutes a finite ring in abstract algebra. The DID is a 160-bit identifier that enables the construction of a mathematical structure that encompasses the characteristics of both a group and a field.

It is comprised of a set of elements with two binary operations, addition and multiplication, which satisfy a set of axioms such as associativity, commutativity, and distributivity. The ring is deemed finite due to its having a finite number of elements. Finite rings are widely employed in various domains of mathematics and computer science, including cryptography and coding theory.

At the protocol layer, we have implemented the concept of a Delegated Session Key, which is used to support various cryptographic verification methods associated with DID (Decentralized Identifier). Currently, the supported signature algorithms include ECDSA-secp256k1, ECDSA-secp256r1, and EdDSA-ed25519.

Application Layer

The nucleus of Rings Network is similar to the Actor Model, and it requires that each message type possess a Handler Trait. This allows for the separation of processing system messages, network messages, internal messages, and application-layer messages.

Dependencies

~15–33MB
~532K SLoC