mirror of
https://github.com/fluencelabs/gitbook-docs
synced 2024-12-04 23:30:23 +00:00
GitBook: [1.0.5] 59 pages modified
This commit is contained in:
boneyard93501
gitbook-bot
parent
f25383402e
commit
106d958c7c
@ -10,9 +10,7 @@ The Fluence Web3 stack enables
|
||||
* extensibility through adapter/wrapper services
|
||||
* efficiencies and improved time to market arising from the reuse of deployed services and significantly reduced devops requirements
|
||||
|
||||
by decoupling business logic from composition, security from business logic and resource management from infrastructure. See Figure 1.
|
||||
|
||||
Figure 1: Decentralized Applications Composed From Distributed Services On P2P Nodes 
|
||||
by decoupling business logic from composition, security from business logic and resource management from infrastructure.
|
||||
|
||||
An integral component of the Fluence solution is the Aquamarine stack comprised of Aqua and Marine. Aqua is a programming language and runtime environment for peer-to-peer workflows. Marine, on the other hand, is a general purpose runtime and associated tooling for multi-module Wasm applications with WASI support and a shared-nothing linking scheme. That is, Marine runs hosted code on nodes and Aqua facilitates the programming of workflows composed from hosted code. In combination, Aqua and Marine enable any distributed application.
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Table of contents
|
||||
|
||||
* [Introduction](README.md)
|
||||
* [Thinking In Distributed](p2p.md)
|
||||
* [Thinking In Aquamarine](p2p.md)
|
||||
* [Concepts](concepts.md)
|
||||
* [Quick Start](quick-start.md)
|
||||
* [Quick Start](quick_start/README.md)
|
||||
|
||||
57
concepts.md
57
concepts.md
@ -1,14 +1,18 @@
|
||||
# Concepts
|
||||
|
||||
|
||||
|
||||
The Fluence solution enables a new class of decentralized Web3 solutions providing technical, security and business benefits otherwise not available. In order for solution architects and developers to realize these benefits, a shift in philosophy and implementation is required. With the Fluence tool chain available, developers should find it possible to code meaningful Web3 solutions in short order once an understanding of the core concepts and Aqua is in place.
|
||||
|
||||
The remainder of this section introduces the core concepts underlying the Fluence solution.
|
||||
|
||||
**Particles**
|
||||
### **Particles**
|
||||
|
||||
Particles are Fluence's secure distributed state medium, i.e., conflict free replication data structures containing application data, workflow scripts and some metadata, that traverse programmatically specified routes in a highly secure manner. That is, _particles_ hop from distributed compute service to distributed compute service across the peer-to-peer network as specified by the application workflow updating along the way.
|
||||
|
||||
Figure 4: Node-Service Perspective Of Particle Workflow 
|
||||
Figure 4: Node-Service Perspective Of Particle Workflow
|
||||
|
||||
|
||||
|
||||
Not surprisingly, particles are an integral part of the Fluence protocol and stack. It is the very decoupling of data + workflow instructions from the service and network components that allows the secure composition of applications from services distributed across a permissionless peer-to-peer network.
|
||||
|
||||
@ -16,7 +20,7 @@ While the application state change resulting from passing a particle "through" a
|
||||
|
||||
As depicted in Figure 4, a particle traverses to a destination node's Aqua VM where the next execution step is evaluated and, if specified, triggered. That is, the service programmatically specified to operate on the particle's data is called from the Aqua VM, the particle's data and workflow \(step\) are updated and the Aqua VM routes the particle to the next specified destination, which may be on the same, another or the client peer.
|
||||
|
||||
**Aqua**
|
||||
### **Aqua**
|
||||
|
||||
An integral enabler of the Fluence solution is Aqua, an open source language purpose-built to enable developers to ergonomically program distributed networks and applications by composition. Aqua scripts compile to an intermediary representation, called AIR, which execute on the Aqua Virtual Machine, Aqua VM, itself a Wasm module hosted on the Marine interpreter on every peer node.
|
||||
|
||||
@ -26,7 +30,7 @@ Figure 5: From Aqua Script To Particle Execution
|
||||
|
||||
Currently, compiled Aqua scripts can be executed from Typescript clients based on [Fluence SDK](https://github.com/fluencelabs/fluence-js). For more information about Aqua, see the [Aqua book](https://doc.fluence.dev/aqua-book/).
|
||||
|
||||
**Marine**
|
||||
### **Marine**
|
||||
|
||||
Marine is Fluence's generalized Wasm runtime executing Wasm Interface Type \(IT\) modules with Aqua VM compatible interfaces on each peer. Let's unpack.
|
||||
|
||||
@ -54,7 +58,7 @@ pub fn greeting(name: String) -> String {
|
||||
}
|
||||
```
|
||||
|
||||
**Service Creation**
|
||||
### **Services**
|
||||
|
||||
Services are logical constructs instantiated from Wasm modules that contain some business logic and configuration data. That is, services are created, i.e., linked, at the Marine VM runtime level from uploaded Wasm modules and the relevant metadata
|
||||
|
||||
@ -64,9 +68,32 @@ Figure 7: Service Composition and Execution Model
|
||||
|
||||
|
||||
|
||||
Services section that services are not capable to accept more than one request at a given time.
|
||||
Please note that services are not capable to accept more than one request at any given time. Consider a service, FooBar, comprised of two functions, foo\(\) and bar\(\) where foo is a longer running function.
|
||||
|
||||
**Modules**
|
||||
```text
|
||||
-- Stylized FooBar service with two functions
|
||||
-- foo() and bar()
|
||||
-- foo is long-running
|
||||
--- if foo is called before bar, bar is blocked
|
||||
service FooBar("service-id"):
|
||||
bar() -> string
|
||||
foo() -> string --< long running function
|
||||
|
||||
func foobar(node:string, service_id:string, func_name:string) -> string:
|
||||
res: *string
|
||||
on node:
|
||||
BlockedService service_id
|
||||
if func_name == "foo":
|
||||
res <- BlockedService.foo()
|
||||
else:
|
||||
res <- BlockedService.bar()
|
||||
<- res!
|
||||
```
|
||||
|
||||
|
||||
As long as foo\(\) is running, the entire FooBar service, including bar\(\), is blocked. This has implications with respect to both service granularity and redundancy.
|
||||
|
||||
### **Modules**
|
||||
|
||||
In the Fluence solution, Wasm IT modules take one of three forms:
|
||||
|
||||
@ -76,7 +103,7 @@ In the Fluence solution, Wasm IT modules take one of three forms:
|
||||
|
||||
It is important for architects and developers to be aware of their module and services construction with respect to state changes.
|
||||
|
||||
**Authentication And Permissioning**
|
||||
### **Authentication And Permissioning**
|
||||
|
||||
Authentication at the service API level is an inherent feature of the Fluence solution. This fine-grained approach essentially provides [ambient authority](https://en.wikipedia.org/wiki/Ambient_authority) out of the box.
|
||||
|
||||
@ -92,21 +119,25 @@ struct SecurityTetraplet:
|
||||
|
||||
SecurityTetraplets are provided with the function call arguments for each \(service\) function call and are checked by the called service. Hence, authentication based on the **\(service caller id == service owner id\)** relation can be established at service ingress and leveraged to build powerful, fine-grained identity and access management solutions enabling true zero trust architectures.
|
||||
|
||||
**Trust Layer**
|
||||
### **Trust Layer**
|
||||
|
||||
Since we're not really ready, should we cut this section?
|
||||
The Fluence protocol offers an alternative to node selection, i.e. connection and permissioning, approaches, such as [Kademlia](https://en.wikipedia.org/wiki/Kademlia), called TrustGraph. A TrustGraph is comprised of subjectively weights assigned to nodes to manage peer connections. TrustGraphs are node operator specific and transitive. That is, a trusted node's trusted neighbors are considered trustworthy.
|
||||
|
||||
The Fluence protocol offers an alternative to node selection, i.e. connection and permissioning, approaches, such as Kademlia, called TrustGraph. A TrustGraph is comprised of subjectively weights assigned to nodes to manage peer connections. TrustGepahs are node operator specific and transitive. That is, a trusted node's trusted neighbors are considered trustworthy.
|
||||
{% hint style="info" %}
|
||||
[TrustGraph](https://github.com/fluencelabs/trust-graph) is currently under active development. Please check the repo for progress.
|
||||
{% endhint %}
|
||||
|
||||
**Scaling Apps**
|
||||
### **Scaling Applications**
|
||||
|
||||
As discussed previously, decoupling at the network and business logic levels is at the core of the Fluence protocol and provides the major entry points for scaling solutions.
|
||||
|
||||
At the peer-to-peer network level, scaling can be achieved with subnetworks. Subnetworks are currently under development and we will update this section in the near future.
|
||||
|
||||
At the service level, we can achieve scale through parallelization due to the decoupling of resource management from infrastructure. That is, seqential and parallel execution flow logic are an inherent part of Aqua's programming model. In order to be able to achieve concurrency, the target services need to be available on multiple peers as module calls are blocking.
|
||||
At the service level, we can achieve scale through parallelization due to the decoupling of resource management from infrastructure. That is, sequential and parallel execution flow logic are an inherent part of Aqua's programming model. In order to be able to achieve concurrency, the target services need to be available on multiple peers as module calls are blocking.
|
||||
|
||||
Figure 8: Stylized Par Execution
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
65
p2p.md
65
p2p.md
@ -1,28 +1,77 @@
|
||||
# Thinking In Distributed
|
||||
# Thinking In Aquamarine
|
||||
|
||||
Permissionless peer-to-peer networks have a lot to offer to developers and solution architects such as decentralization, improved request-response data models and zero trust security at the application and service level. Of course, these capabilities and benefits don't just arise from putting libp2p to work. Instead, a peer-to-peer overlay is required. The Fluence protocol provides such an overlay enabling a powerful distributed data routing and management protocol allowing developers to implement modern and secure Web3 solutions.
|
||||
Permissionless peer-to-peer networks have a lot to offer to developers and solution architects such as decentralization, control over data, improved request-response data models and zero trust security at the application and service level. Of course, these capabilities and benefits don't just arise from putting [libp2p](https://libp2p.io/) to work. Instead, a peer-to-peer overlay is required. The Fluence protocol provides such an overlay enabling a powerful distributed data routing and management protocol allowing developers to implement modern and secure Web3 solutions. See Figure 1 for a stylized representation decentralized applications development by programming the composition of services distributed across a peer-to-peer network.
|
||||
|
||||
**Improved Request-Response Model**
|
||||
Figure 1: Decentralized Applications Composed From Distributed Services On P2P Nodes
|
||||
|
||||
|
||||
|
||||
###
|
||||
|
||||
### Aquamarine
|
||||
|
||||
As a complement to the protocol, Fluence provides the Aquamarine stack aimed at enabling developers to build high-quality, high-performance decentralized applications. Aquamarine is purpose-built to ease the programming demands commonly encountered in distributed, and especially peer-to-peer, development and is comprised of Aqua and Marine.
|
||||
|
||||
[Aqua](https://doc.fluence.dev/aqua-book/), is a new generation programming language allowing developers to program peer-to-peer networks and compose distributed services hosted on peer-to-peer nodes into decentralized applications and backends. Marine, on the other hand, provides the necessary Wasm runtime environment on peers to facilitate the execution of compiled Aqua code.
|
||||
|
||||
A major contribution of Aquamarine is that network and application layer, i.e., [Layer 3 and Layer 7](https://en.wikipedia.org/wiki/OSI_model), programming is accessible to developers as a seamless and ergonomic composition-from-services experience in Aqua thereby greatly reducing, if not eliminating, common barriers to distributed and decentralized application development.
|
||||
|
||||
### **Improved Request-Response Model**
|
||||
|
||||
In some network models, such as client server, the request-response model generally entails a response returning to the request client. For example, a client application tasked to conduct a credit check of a customer and to inform them with a SMS typically would call a credit check API, consume the response, and then call a SMS API to send the necessary SMS.
|
||||
|
||||
Figure 2: Client Server Request Response Model
|
||||
|
||||
|
||||
|
||||
|
||||
The Fluence peer-to-peer protocol, on the other hand, allows for a much more effective Request-Response processing pattern where responses are forward-chained to the next consuming service\(s\) without having to make the return trip to the client. See Figure 3.
|
||||
|
||||
Figure 3: Fluence P2P Protocol Request Response Model
|
||||
|
||||
|
||||
|
||||
|
||||
In a Fluence p2p implementation, our client application would call a credit check API deployed or proxy-ed on some peer and then send the response directly to the SMS API service possibly deployed on another peer -- similar to the flow depicted in Figure 1.
|
||||
|
||||
Such a significantly flattened request-response model leads to much lower resource requirements for applications in terms of bandwidth and processing capacity thereby enabling a vast class of "thin" clients ranging from browsers to IoT and edge devices truly enabling decentralized machine-to-machine communication.
|
||||
|
||||
**Zero Trust Security**
|
||||
### **Zero Trust Security**
|
||||
|
||||
The [zero trust security model](https://en.wikipedia.org/wiki/Zero_trust_security_model) assumes the worst reality, i.e., a breach, and proposes a "never trust, always verify" approach. This approach is inherent in the Fluence peer-to-peer protocol and Aqua programming model as every service request can be authenticated at the service API level.
|
||||
The [zero trust security model](https://en.wikipedia.org/wiki/Zero_trust_security_model) assumes the worst, i.e., a breach, at all times and proposes a "never trust, always verify" approach. This approach is inherent in the Fluence peer-to-peer protocol and Aqua programming model as every service request can be authenticated at the service API level. That is, every service exposes functions which may require authentication and authorization. Aquamarine implements SecurityTetraplets as verifiable origins of the function arguments to enable fine-grained authorization.
|
||||
|
||||
Overall, the Fluence solution enables a modern Web3 runtime and development environment on top of a peer-to-peer stack that allows developers to build powerful and secure distributed applications on thin clients and powerful servers alike.
|
||||
### Service Granularity And Redundancy
|
||||
|
||||
Services are not capable to accept more than one request at any given time. Consider a service, FooBar, comprised of two functions, foo\(\) and bar\(\) where foo is a longer running function.
|
||||
|
||||
```text
|
||||
-- Stylized FooBar service with two functions
|
||||
-- foo() and bar()
|
||||
-- foo is long-running
|
||||
--- if foo is called before bar, bar is blocked
|
||||
service FooBar("service-id"):
|
||||
bar() -> string
|
||||
foo() -> string --< long running function
|
||||
|
||||
func foobar(node:string, service_id:string, func_name:string) -> string:
|
||||
res: *string
|
||||
on node:
|
||||
BlockedService service_id
|
||||
if func_name == "foo":
|
||||
res <- BlockedService.foo()
|
||||
else:
|
||||
res <- BlockedService.bar()
|
||||
<- res!
|
||||
```
|
||||
|
||||
|
||||
As long as foo\(\) is running, the entire FooBar service, including bar\(\), is blocked. This has implications with respect to both service granularity and redundancy.
|
||||
|
||||
### Summary
|
||||
|
||||
Programming distributed applications on the Fluence protocol with Aquamarine unlocks significant benefits from peer-to-peer networks while greatly easing the design and development processes. Nevertheless, a mental shift concerning peer-to-peer solution design and development process is required. Specifically, the successful mindset accommodates
|
||||
|
||||
* an application architecture based on the composition of distributed services across peer-to-peer networks by decoupling business logic from application workflow
|
||||
* a services-first approach with respect to both the network and application layer allowing a unified network and application programming model encapsulated by Aqua
|
||||
* a multi-layer security approach enabling zero-trust models at the service level
|
||||
* a flattened request-response model enabling data free from centralized control
|
||||
* a services architecture with respect to granularity and redundancy influenced by service function runtime
|
||||
|
||||
|
||||
@ -1,5 +1,7 @@
|
||||
# Quick Start
|
||||
|
||||
|
||||
|
||||
The Fluence solution enables a new class of decentralized Web3 solutions providing technical, security and business benefits otherwise not available. In order for solution architects and developers to realize these benefits, a shift in philosophy and implementation is required. With the Fluence tool chain available, developers should find it possible to code meaningful Web3 solutions in short order once an understanding of the core concepts and Aqua is in place.
|
||||
|
||||
The remainder of this section introduces the core concepts underlying the Fluence solution.
|
||||
@ -110,3 +112,5 @@ Figure 8: Stylized Par Execution
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user