We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Need for secure composition. Aquamarine language.

00:00

Formal Metadata

Title
Need for secure composition. Aquamarine language.
Title of Series
Number of Parts
637
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Aquamarine is the multi-process composition medium based on pi-calculus, designed for distributed applications/backends, both in private deployments and open networks. Aquamarine scripts define the topology of the execution (when and where to move control flow) and data dependency graph (what results and what arguments to pass where), essentially describing the composition of (micro)services, e.g. using one service's output as another service's input. The language primitives are based on pi-calculus operations describing certain topological effects and secured by cryptographic signatures of involved peers. The Aquamarine approach allows building distributed systems of any complexity, effectively expressing network behavior.
Formal languageOpen setPerimeterInformation securityService (economics)Mobile appEndliche ModelltheorieCodeFunction (mathematics)Product (business)System callComputer networkGame controllerCommunications protocolControl flowoutputComputational physicsProcess (computing)Local ringNetwork topologyInvariant (mathematics)Sound effectData modelLevel (video gaming)Musical ensembleInformation securityOpen setRankingComputer networkFormal languageNetwork topologyCodePeer-to-peerControl flowInvariant (mathematics)Category of beingCartesian coordinate systemAuthorizationProduct (business)Virtual machineSoftware developerBusiness modelOpen sourceFunctional programmingCommunications protocolComplex (psychology)System callOnline helpoutputCASE <Informatik>SurfaceProcess calculusProcess (computing)TheoryNeuroinformatikSound effectFunction (mathematics)PerimeterPrime idealSingle-precision floating-point formatRevision controlState of matterDifferent (Kate Ryan album)Gateway (telecommunications)Roundness (object)Dependent and independent variablesService (economics)MereologyData managementFocus (optics)Condition numberCombinational logicDemosceneGauge theoryBoss CorporationCoefficient of determinationData centerData miningBuildingMultiplication signLocal ringMetropolitan area networkDirected graphLevel of measurementArithmetic meanUrinary bladderForcing (mathematics)Archaeological field surveyLatent heatComputer animation
Regulärer Ausdruck <Textverarbeitung>Process (computing)Computer networkDeterminismoutputFunction (mathematics)Combinatory logicReplication (computing)Group actionDependent and independent variablesConsistencyInformation securityOperator (mathematics)Network topologyGraph (mathematics)FactorizationStack (abstract data type)Run time (program lifecycle phase)Assembly languageParticle systemRule of inferenceProof theoryService (economics)Scripting languageCalculusFormal languageCompilerCompilation albumOpen setCodeControl flowPeer-to-peerInformation securityProcess (computing)Rule of inferenceEndliche ModelltheoriePerimeterProof theoryoutputParticle systemParallel computingScripting languageRun time (program lifecycle phase)Service (economics)Operator (mathematics)Matching (graph theory)Coordinate systemConsistencyCategory of beingCombinational logicDependent and independent variablesSystem callAlgorithmLimit (category theory)Term (mathematics)Arithmetic meanElectronic signatureLevel (video gaming)Correspondence (mathematics)Self-organizationNeuroinformatikRepository (publishing)Link (knot theory)Computer networkElectronic mailing listCartesian coordinate systemComplete metric spaceFluxOpen setGraph (mathematics)Latent heatFormal languageHeegaard splittingRepresentation (politics)Function (mathematics)Duality (mathematics)Set (mathematics)Similarity (geometry)Coefficient of determinationDemoscene9 (number)Web 2.0Graph (mathematics)Speech synthesisMusical ensembleMessage passingUsabilityCore dumpGroup actionCondition numberMultiplication signProduct (business)Error messageState of matterCASE <Informatik>FamilyAssembly languageInternetworkingMachine visionMedical imagingExecution unitInductive reasoningAmenable groupSession Initiation ProtocolCalculusSoftware developerCommunications protocolBroadcasting (networking)Single-precision floating-point formatLocal ringPhysical system
Point cloudElement (mathematics)Computer animation
Transcript: English(auto-generated)
Hi folks, my name is Dmitry and today I will be speaking about the need for secure composition and the reasons behind Ekumarine. First of all, how we got there?
We want to enable open applications. This is the new concept of removing security perimeter around the services and having microservices open for composition, for making new applications, composing new applications from running services, reusing both code and data.
And to do so, we need to decouple ownership or hosting from authorship from the authors of the code to enable new business models and to incentivize developers, including the open source developers, which is important how we approach that. We consider applications as experiences and these experiences are delivered as front-end
products so that you take a product and you interact with it and you have an experience. This experience is composed and brought to the user, is composed from function calls. Functions is a code which resides somewhere. It could be grouped into domain-specific microservices.
It may be authored by different developers and it is running on machines on certain peers. And these peers could have different owners, they could reside in different data centers. You may be peer on your own or you can host your own machine or you can use some
shared resources and so on. So we want to make an open network from these peers and it means that it needs to be self-coordinated. The peers are of the same rank. We want to get rid of gateways and controllers as they make a difference.
And actually they constitute this security perimeter and it disables the composability of microservices as they are hidden behind the gateway. And also want the self-coordination to be efficient. That means if we can get rid of controllers, then we don't need to have round trips
between service nodes and controllers. Each node, each peer can take the full responsibility for choreographing itself, for managing and coordinating itself. And to do so we want to have recursive routing, which means that there is no
need to send acknowledge back to the requesting node until it's explicitly stated that the acknowledge is needed. So this is about approach. And what we did is Ecomarine is the name of the composability medium, which is a part of the Fluence network.
It's a new language and protocol to compose distributed function calls and to enable open applications. So my main focus today is the language and why do we need the new language. So the problem for the language and for the runtime, for the composability medium
can be stated as following. First of all, you want to call functions on different peers. And to do so, you want to describe how to get from one peer to another, how the control flow should flow. So this is about topology and the network effect, how the control flow goes
from peer to peer. Second, on every peer, we want to run some computations and we want to use outputs from one functions as inputs for another functions. And we want to do so in a secure way. So it's about data and about the computational effect that happens on a single node.
So at first, let's take a look on what happens on a single peer, how the peer could approach it. So when control flow is moved to a single peer, what it can do?
It definitely can do all the computations that could be done locally. And what it cannot do locally, it needs to delegate to another peers which are responsible for the subsequent computations. So we can describe a single processing step like the following.
We have some incoming data package or network package holding some code and some data. This data is used locally to produce data prime. And we also have the code that expresses what computations to perform
on this node and what topology should be involved next. What are the next peers should take the data prime and do their job? And it looks like functional languages where we have the effects and data, and we can treat them separately.
So the data is being modified on a single node, on a single peer, on each peer. And we want to have some security invariants, like we want to prevent from a man-in-the-middle attack so that data can't be modified.
We want to stand the replay attacks. We don't want to reach conflict state of the data. So data should be conflict-free, replicated data type, CRDT. And this is the invariants which are held with the help of a single peer. Details of how we get it are beyond of the scope of this talk,
but let's assume that we just have it. Then let's consider control flow, what it could look like, how we could model the network effects and this moving of execution from peer to peer.
Desired properties for this model. First, it's simplicity. As distributed networks are already such a complicated topic, it would be nice not to introduce too much complexity for network effects. So simplicity is the must.
But even having it simple, we want to have it flexible, and we don't want to introduce unnecessary restrictions on the use cases and topologies which we could use. And finally, as we want to have open applications in permissionless networks, we need to take care of security.
At least we need to keep the invariants which were described before, and it's better not to introduce too much attack surface as the network effects. And here we have p-calculus, process calculus. It's a theory that expresses how the control flow,
how the execution goes from process to process. Processes being either local or network processes, and it fits perfectly for the non-deterministic network behavior. And by the way, real world is non-deterministic, so it's also nice.
Let's take a look how it fits our desired properties. First of all, p-calculus is simple. This is the complete list of operations that we can do. We can send a message, we can receive a message, we can do combinators like do subsequent computations,
coproduct, product, parallel computations. We have some branching support with a match and mismatch. We can introduce local names, local variables, and we can do replication, which means that there are resources in the network
which are not consumed with their use. Like if you call a function, it doesn't disappear after the call. And thanks to the theory, we can be sure that it is enough. Enough for what? For flexibility. With p-calculus, you can do a lot of things. You can describe very complex systems,
starting with a request response or another control flow for a single action, like a controller. Or you can do publisher, subscriber, broadcast, COSIP for a network as a whole or for a subnetwork. It's possible to implement CADEMLE, to describe CADEMLE and p-calculus
and other eventual consistent algorithms. You even can code and describe and reason about strong consistency in terms of p-calculus. So p-calculus is the foundation for coordination networks development, and it doesn't limit us on its own.
I think it is wonderful. And finally, p-calculus is secure. Well, security is not a specific property of p-calculus, but it could be derived thanks to simplicity and a very strict composition capabilities. So if we have security considerations
for all the operators that they retain signatures on data, that there is no way to fake anything and so on, then by induction, we can assume that the complex scenario built from these operators is also secure
in the same meaning of security. But for the open network, it depends. It also depends on the lower level of security to stand the Eclipse attack and Sybil attack influence. We have a trust graph for it, but it's also out of scope of this talk,
but we have it. And that's the reasoning for Ecomarine. Ecomarine intermediate representation, the low level language that we use to describe composition and control flow between the peers corresponds to p-calculus. It's just p-calculus put into practice.
It's not the complete list of operations and we have a match mismatch and similar things. You can take a look on it in documentation, but this is the inspiration for here and the main reason. And this makes it possible to factor the open application into two stacks,
into network stack, which is handled with Ecomarine and low level representation, the code representation for Ecomarine is air and computations stack influence is handled with Fluence compute engine that runs WebAssembly and we have the low level representation
of a code, it's WASM. On each node, that's about the protocol, how Ecomarine is processed. Ecomarine processing is structured with particles. Each particle contains some code, it's an air script and data.
When this particle comes to a peer, all the proofs and security guarantees are verified on this peer and air script is interpreted locally according to p-calculus based set of rules. Services are called within WebAssembly runtime
on the local node. This takes data as input and provides the modified data, which contains the new proofs for the new outputs. So it's signed, both inputs and outputs are signed by this peer. And finally, the particle is sent to the next peers
who needs to process it. And the next peers, the list of next peers is derived from the p-calculus based set of rules from the air script. The question is, can it be another language? Why air, why not something else? Of course, it can be another language, but in any case,
we need to consider this duality of having network specific control flow and special reasoning about control flow security. And we have the computations which could be performed locally with their own security model.
So you can take any language and split computations with the control flow branching or moving, compile all of these into low level representation into air for control flow and the WebAssembly for computations
and use it to form a particle, to send it to the Flux network and to have everything secure, flexible, concise, and nice. So to conclude, what are the practical consequences? First of all, composition in an open network requires security to be taken into account
and it's really important and without it, the open applications are not possible and composition cannot be secured. Ecomarine is a p-calculus based approach to composition for permissionless networks.
It's very flexible yet secure and open applications, meaning this removing of security perimeter and so on, can be built with WebAssembly for computations and air for control flow. Thank you for your attention. We have all our code open
in Fluence Labs organization. Here's the link for Ecomarine repository. Take a look on this syntax. We have some docs and examples. Thank you for your attention. Bye-bye.