fluencelabs/rfcs
1
0
Fork 0
mirror of https://github.com/fluencelabs/rfcs synced 2025-04-24 18:52:16 +00:00
Code Issues Projects Releases Wiki Activity

img heights

Browse Source
This commit is contained in:
dmitry 2020-11-30 18:52:06 +03:00
parent 235c2a1e92
commit 8228715bd8
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
0-overview.md
View File

@ -29,7 +29,7 @@ Below we discuss the main aspects of the Fluence protocol and how the pieces wor
One of Fluence’s primary innovations is to allow the application architecture to have a flexible and custom security perimeter that includes both private and public components. A developer can use Fluence to draw a new security perimeter around the required components to make them work as a single application. Fluence considers these components and the set of distributed execution flows over them as an application. Every flow describes which services must be called and how data must be transferred between them to implement a specific part of the application’s business logic. Services may reside on different cloud platforms, vendors, or servers but communicate with each other over a common protocol.
<img src="0-overview/0-overview.png"/>
<img src="0-overview/0-overview.png" height="300"/>
Packets with the execution flow travel from peer to peer in the Fluence Network. On every peer, services make computations and perform effects: change state and call external APIs. Only the peers and services authorized to handle the request participate in its handling and no intermediary is able to change the execution flow or data.
@ -216,13 +216,13 @@ WebAssembly Interface Types provide a consistent API for services and also link
To describe relationships between peers on the decentralized network, Fluence uses a method similar to the [Web of Trust](https://en.wikipedia.org/wiki/Web_of_trust) concept. Peers are identified by their Public Keys. Cryptographic signatures are used to authenticate network messages and to protect transmitted data from unauthorized changes.
<img src="0-overview/2-tg-lens.png"/>
<img src="0-overview/2-tg-lens.png" height="400"/>
Direct relationships between peers constitute Trust and a collection of such relationships forms a graph: the TrustGraph. If a peer “trusts'' another peer, it forms an edge in the TrustGraph, which is represented as a cryptographically proven entity that tethers two Peer IDs.
<img src="0-overview/3-certificate.png"/>
<img src="0-overview/3-certificate.png" height="300"/>
A sequence of Trusts forms a Certificate. Certificates are particularly useful as they allow you to manage trust relationships not knowing all peers in advance: if PeerA explicitly trusts RootZ, it means PeerA trusts other yet-unknown peers trusted by RootZ – but to a lesser extent.