Need for secure composition. Aquamarine language.
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.
Kurinskiy, Dmitry
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.
 Hi folks, my name is Dmitry and today I will be speaking about the need for secure composition and the reasons behind the Echo Marine. 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 using 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. Experience 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 a 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 we 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 or managing and coordinating itself. And to do so we want to have recursive routing which means that there is no need to send a knowledge back to the pre-questing node until it's explicitly stated that the technology is needed. So this is about approach. And what we did is a ecumrain. It's 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 the pathology 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 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 peer 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, calling 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 the pollages 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 invariance. Like we want to prevent from man and the middle attack so that data can't be modified. We want to standard play 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 invariance which are held with the help of a single peer. Details of how we get it beyond 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. Design properties for this model first is 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 a 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 apologies which we could use. And finally, if we want to have open applications in permissionless networks, we need to take care of security. At least we need to keep the invariance which we 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, process being either local or network process. 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 desires, design 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, co-product, 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, gossip for a network as a whole or for a subnetwork. It's possible to implement cademlia to describe cademlia 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 also depends on the lower level of security. To stand the eclipse attack and civil attack influence, we have a truss graph for it, but it's also a scope of this talk, but we have it. And that's the reasoning for a covering. A covering 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 error and the main reason. And this makes it possible to factor the open application into two stacks, an internet works stack, which is a handled with a equipment and low level representation, the code representation for a command is error and computation stack influences handled with a fluence compute engine that runs WebAssembly and we have the low level representation of code meets wasm. On each node, that's about the protocol, how kumarin is processed. A current processing is structured with particles. Each particle contains some code. It's an error script and data. When this particle comes to appear, all the proofs and security guarantees are verified on this peer and error 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 error script. The question is, can it be another language? Why error? 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 a control flow branching or moving, compile all of these into low level representation, enter error for control flow and WebAssembly for computations and use it to form a particle to send it to the fluency network and to have everything secure, flexible, concise and nice. So to conclude what 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. Equal Marine is a P calculus based approach to composition for permission less 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 error for control flow. Thank you for your attention. We have all our code open in Fluence Labs organization. Here's the link for Equal Marine repository. Take a look on this index, we have some docs and examples. Thank you for your attention. Bye-bye.
 Hi folks, my name is Dmitry and today I will be speaking about the need for secure composition  and the reasons behind the Echo Marine.  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  using 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.  Experience 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 a 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 we 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 or managing and  coordinating itself.  And to do so we want to have recursive routing which means that there is no need to send  a knowledge back to the pre-questing node until it's explicitly stated that the technology  is needed.  So this is about approach.  And what we did is a ecumrain.  It's 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 the pathology 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 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 peer 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, calling 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 the pollages 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 invariance.  Like we want to prevent from man and the middle attack so that data can't be modified.  We want to standard play 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 invariance which are held with the help of a single peer.  Details of how we get it beyond 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.  Design properties for this model first is 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 a 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 apologies which we could use.  And finally, if we want to have open applications in permissionless networks, we need to take  care of security.  At least we need to keep the invariance which we 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, process being either local or network process.  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 desires, design 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, co-product, 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, gossip for a network as a whole or for a subnetwork.  It's possible to implement cademlia to describe cademlia 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 also depends on the lower level of security.  To stand the eclipse attack and civil attack influence, we have a truss graph for it, but  it's also a scope of this talk, but we have it.  And that's the reasoning for a covering.  A covering 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 error and the main reason.  And this makes it possible to factor the open application into two stacks, an internet  works stack, which is a handled with a equipment and low level representation, the code representation  for a command is error and computation stack influences handled with a fluence compute  engine that runs WebAssembly and we have the low level representation of code meets wasm.  On each node, that's about the protocol, how kumarin is processed.  A current processing is structured with particles.  Each particle contains some code.  It's an error script and data.  When this particle comes to appear, all the proofs and security guarantees are verified  on this peer and error 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 error script.  The question is, can it be another language?  Why error?  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 a control flow branching or moving,  compile all of these into low level representation, enter error for control flow and WebAssembly  for computations and use it to form a particle to send it to the fluency network and to have  everything secure, flexible, concise and nice.  So to conclude what 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.  Equal Marine is a P calculus based approach to composition for permission less 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 error for control flow.  Thank you for your attention.  We have all our code open in Fluence Labs organization.  Here's the link for Equal Marine repository.  Take a look on this index, we have some docs and examples.  Thank you for your attention.  Bye-bye.
fluence_aquamarine101_0_179.png fluence_aquamarine101_180_443.png fluence_aquamarine101_444_491.png fluence_aquamarine101_492_1427.png fluence_aquamarine101_1428_2627.png fluence_aquamarine101_2628_4283.png fluence_aquamarine101_4284_4871.png fluence_aquamarine101_4872_6167.png fluence_aquamarine101_6168_6335.png fluence_aquamarine101_6336_6935.png fluence_aquamarine101_6936_8123.png fluence_aquamarine101_8124_9191.png fluence_aquamarine101_9192_9515.png fluence_aquamarine101_9516_10847.png fluence_aquamarine101_10848_11687.png fluence_aquamarine101_11688_12839.png fluence_aquamarine101_12840_14099.png fluence_aquamarine101_14100_15563.png fluence_aquamarine101_15564_15683.png fluence_aquamarine101_15684_16391.png fluence_aquamarine101_16392_17135.png fluence_aquamarine101_17136_18827.png fluence_aquamarine101_18828_20327.png fluence_aquamarine101_20328_20375.png fluence_aquamarine101_20376_21455.png fluence_aquamarine101_21456_21899.png fluence_aquamarine101_21900_22023.png