 Okay, so thank you everyone for coming What I will try to do now is not destroy what guide is straight But what like try to land what we have now and what we can do right now with with IPC because there's an MVP And actually you can start using it and hopefully in the next few months You will be able to start to deploy applications over this this system I don't know if Marco has convinced you by now, but I Think we all agree that consensus the consensus layer of blockchains is It's one of the key bottlenecks in the web 3 we need blockchains to for coordination and orchestration in web 3 Which means that we really need to fix this if we want to bring the type of web 2 applications To the web 3 space because if we need a blockchain we need consensus and if we need consensus We really need to scale this layer if we look at Marco explained a bit what our what are our targets when And in all the research that we're doing and IPC is mainly focused on this There was a question over there on what is the key element that IPC has compared to to others One that I think that is really important is partition tolerance So if you see polka dot and you disconnect a parachain from the from the main chain of polka dot You cannot keep working if you go to Cosmos you have to rely on the Cosmos hops So you have several limitations. There's there's no way you can have a partition of the network with IPC We can do that like we could have a local data center doing operations and whenever you recover the connection You'll see in a moment in the implementation how this match up But you would be able to propagate that information and this actually IPC you see that there are other things like censorship resistance Be having independence. We don't enter into that like with IPC We were focusing on this like trying to have scalability fast consensus and have this partition tolerance that we think that in blockchains this is not really true right now and This is actually the motivation. I mean if you go to the sharding approaches that we see out there They are Explicitly partitioning the state. So you're not letting users actually partition the state how they want or deploy the consensus algorithm They want it's really specific. So if you go to polka dot if you go to Cosmos if you go to any of these Scaling approaches you don't have a way of configuring the system for your needs And actually this is one of the things that we wanted to fix with IPC Not only scalability but also let the application because we cannot come up with the best trade-off between security and Performance and what we say is that instead of trying to find the one-size-fits-all system Let's try and let users configure the system and have a flexible system that allows us and allows application to actually come up with what they need and That's what we're trying with IPC So we're trying to give a framework for anyone to be able to configure the system and configure the subnet to what they actually Need and in the process what we realize is that it's actually a good idea to allow Consensus community and like the distributed system community to test stuff because if you have a low cost low barrier of entry Way of deploying your own blockchain and deploying your own consensus algorithm because we came up with interfaces abstractions and so on that Anyone can reuse to foster innovation like test their ideas So we're really looking forward to foster these kind of collaborations and like invite you to hack your own consensus into IPC Or try your layer-to-approach in an IPC subnet or whatever you can come up with So this is kind of like the motivation when we started designing IPC and By now I think that Hopefully guy has convinced you of what is the value of IPC and how it works I'm gonna go a bit deeper into how we implement this We already have an MVP and we will have a test net soon and how it works and or what you can do as a user with IPC is the following so let's imagine again the The Falcon mainnet as the root chain for instance where we have 30 seconds block times and we could even have a parallel check pointing Network like Bitcoin. We actually have it in the case of Falcon But the point is that with these 30 seconds even improve of work or with these 30 second block times We cannot deploy our defi application or we cannot deploy the only fans as the new key application of with three So all of these applications what they will be able to do as users is and they actually can do now is Spawn their own subnets. So as a user In in IPC what you will be able to say is hey I want to spawn a new subnet with these specific consensus and these specific properties and we want to Validate transactions in parallel to the main chain while keeping the ability of Interoperating with the rest of the networks in the system and this is recursive. So at some point like the only fancy is so Popular that we're gonna divide the deployment into different zones different availability sounds the same way that AWS works or whatever in this case we would be able to Recursively from a subnet keep growing a subnet One of the of the key properties that we have security wise because we don't guarantee security within a subnet like Three friends could spawn their own subnet have their the dumbest Consensus where only one of them validates and that's it But we every subnet we enforce in every subnet a firewall requirement What we mean with a firewall requirement is that the if there's an attack in a subnet? And there's a malicious committee in a subnet the impact that it can have in the upper layers of the hierarchies at most of the amount of Filecoin or the amount of native token if we're in another chain that we have injected in that subnet So the circulating supply in that subnet we can discuss on how we implement this and so on afterwards But this is one of the things that we want We don't want to force a security guarantee Which is something that happens in Polkadot with the the audits I think they call it something like that or in Cosmas with the hubs here We want to leave users like free for all and for you to configure whatever security guarantees for real that you need and How do we implement this right now? So I don't know if many of you know Filecoin is gonna ship soon. I mean actually it's already in mainnet but you will have a way of deploying user defined actors and How we are implementing IPC is through a set of actors or smart contracts or the Filecoin network Something that we want to do in the future is also translate them to solidity so that you could have IPC in any theorem for instance, but The the two key components in in IPC is to smart contracts What we call the IPC gateway that is the main actor that implements all of the logic for a subnet and for the root net For IPC and then a subnet actor and this subnet actor defines all of your policies for the subnet and defines how you want your subnet to operate So if I'm a user and I want to deploy right now a new subnet in in IPC What I would do is deploy my subnet actor and say hey, I want to deploy a subnet with this consensus algorithm I want users or validators to join me to have this collateral I want these security guarantees you would define there and implement an interface for a subnet actor from there Like me and my friends would be able to start mining in a parallel chain With the caveat that right now we are just a sidechain if we really want to become a subnet able to interact with the rest of The hierarchy I would have to register to the IPC gateway and the IPC gateway has a and this is the one that actually enforces this Firewall requirement the IPC gateway is the the actor in our parent that will Enforce me certain requirements if I want to interact with the rest of the hierarchy So in this case, I would have to put some collateral in order to to validate and be able to commit Some of my checkpoints and I incur my security to the chain in the same way another subnet would do exactly the same If another user wants to deploy a subnet they just deploy the subnet actor to find the behavior for their subnet and then register to the IPC gateway so that We can start sharing information with other subnets interacting with the rest of the subnet and in order to enforce these firewall requirement Huh, I mean the way in which we implement this at a peer level So this is like the architecture of the system But if we go like Marco mentioned that we are implementing this right now over the Fargo and client the way this looks like It's super simple like we share the transport layer and then we spawn complete new stacks for each of these subnets So in the end the when you deploy A new subnet and you start syncing from your peer with a new subnet What are you doing is having a new independent message pool a new independent consensus? The same VM and the same state tree because we keep the semantics That's one of the tricks that we're doing all of our plugins are IP LD based So they actually speak the same language and this is an advantage because it's a way of of having this Interoperability by design and the only thing that we share is a transport layer So we share the broadcast layer so that we think we have a way of exchanging these messages between the different subnets and the different Peers that may be syncing with different subnets and that's how it looks like from like Implementation perspective at a peer level and then I mentioned that One of the things that we can do a subnet sees anchor our security to our parent chain In the end like this checkpointing protocol what it does is it has two two purposes The first one is to anchor the security and Periodically anchor some proof of the state of my subnet so I would be able to for instance This is completely like the subnet actor can define what we include in a checkpoint and what we're gonna propagate up But the kind of information that we could have is for instance Hey, I'm gonna build a sake a proof kind of a roll-up approach to Batch some transactions and have a way of having of leaving there a piece of my state so that I can build for Proofs so we would be able to have a subnet that behaves like a rope Or we could do something as naive as we're going doing now, which is propagating some of my tip sets so that I Leave small pieces of my chain and I can build different types of fraud proofs or or or ways of proving misbehavior in my subnet So this is something that the checkpoint protocol would allow us and also we use the checkpoint protocol as the way of Because all of the subnets so one of the requirements also for some as I forgot to mention is that they need to sync with their parents because they Need to listen to events in the IPC gateway and the subnet actor to see what is happening there and The way so go sending information from the top of the of the tree down is easy because we are all syncing with our parent But sending in it up is not as easy because like I don't want to force my parent to avoid state explosion I don't want my parent to be listening to all of its children So how we fix this is through the checkpoints. We use checkpoints not only to anchor state security But also to give it as a pipe to send information from the bottom layers of the of the tree up so In the end like again This is we're trying this to be as general as we can and make it as as flexible as possible so that you can Implement whatever model you want, but how it works right now is that we divide so we have a Checkpoint period that the subnet can choose for instance these 100 blocks or epochs or what how I mean depending on the blockchain you can call these these time as you want and What we will do is that when in epoch 100 We open the checkpointing window for it epoch 200 and we will start collecting So the IPC gateway start collecting all of the cross-net messages that need to be propagated up And it tries is start building whatever Information and proof of state of the subnet that we want to propagate up when we reach the end of the Checkpointing window. We have all of the information and the validators of the subnet Again like in the subnet right now in the current implementation what we Wait is for a super majority of the committee in the subnet to sign the checkpoint and propagate it to the parent But like we also we are also exploring to use what we're using for checkpoint like threshold signature to propagate information So you could come up with whatever Scheme you want, but the idea is that once everyone agrees that the checkpoint epoch has finished. There's a Protocol that decides how we're gonna sign that checkpoint and propagate it up for so that it's verified by the subnet actor So in parallel, there's the signing of the previous epoch and we open the The window for the next step and in this way periodically we are getting information that needs to be propagated up And we have like kind of a clock of the system I don't know if someone is an electrical engineer here, but when we're building like Circuits you have a the main clock and then you can have like different periods of clocks That's the idea behind this like to propagate information following these clocks of each subnet And yeah, so this is periodic and I've been talking about anchoring security and sharing information But how do we share this information by now? Hopefully you kind of got an idea. We have like two main primitives and if you've seen So this is the first thing where guy and I disagreed a bit and where he poked in the hole and is the way of We propagate information. So in the We have two main primitives to propagate information. We have what we call the top-down messages That is the information that comes from the top of you from your parent or the top of the hierarchy down This one is quite easy because as we are forcing Child subnets to be able to sign with their parents because they need to keep Track of the events in these two special actors. That's quite straightforward. We just listen to events We pass the events through the consensus engine of the subnet and we can all agree that something happened in the parent And something has to go down For the bottom up we have checkpoints. So that's also easy. We use the checkpoint protocol We introduce some information there and we propagate it up Actually the way we propagate information up and down is not I mean we can discuss it and there are you can check The spec, but we I mean we are in an IPLD based which means content address Blockchain so every information is content address. We actually don't propagate full information We propagate pointers to the information. That's one of the advantages of having a content address blockchain We don't really need to propagate all of the information but with pointers. We already have protocols to To resolve this information and this content in the corresponding subnet and the corresponding blockchains And this is where Guy and I mainly Disagreed before we had this path transaction that in the end it was a combination of bottom up transactions and top down These will probably be removed soon because as With guys model we want to restrict as much as possible The communication before you could like trigger a transaction that went Several levels up and several levels down which introduce this problem that I think someone asked How do you handle gas fees and so on it really made it really complex. So that's how guy came up with this model Let's make it instead a single atomic Transaction let's make it small atomic Transactions that we can reason about so that's like the main chain that you may see in the spec these days and that will probably change with all of the things that a guy has been working on and Marco also mentioned because okay, this is great. We can send information from one subnet to the other But what happens if we really need to use state actual state? Not only the native token but actual state that leaves in a smart contract in some other subnet So for that we came up with a cross subnet atomic execution that I don't think I'll have time to explain But basically it's a protocol again, these these are several we were trying to come up with the primitives and there are several ways as an Synchronous approach and an asynchronous approach in which you can implement this But the properties that we're looking for the reference implementations that we will ship with IPC is to have atomicity timeliness and Unforgeability so to have a way of locking state the same way you do an atomic swap With some asset do kind of atomic swaps, but with state So have a way in which we log state in the subnets that are involved And then we have the parent chain or the common parent for both or all the subnets involved to be the judge of the Execution so we log state we have a primitive to log state in the subnet And then we have the common parent as a judge that says hey either the log has been correct There are a set of primitives again like we can go in depth. There's a spec that explains it This is also gonna change because we realize that we can make it simpler. So guy keeps poking But yeah, the idea is that we not only should be able to exchange some Native token, but we should be able to actually perform Executions with state involving several in some Guy already Talked a bit about this like there are other approaches We are not that novel but like we think that we can take ideas and inspiration from several of these places And we have discussions this Marco already mentioned this also like we are really open on our work So if you think that you have an idea or you say hey, I've seen that avalanche subnets are way better than what you're doing Please let us know like we have a This is an example of a github discussion where we're discussing like what are the comparisons like computer a of analysis compared to to AC we would love to story IPC we will love to know more about this and I mean if you like this and you want to try it what we have right now, so we have a deco which is these It's a fork of Farquhen where we implement all of our ideas research ideas So it's not production ready is where we implement our MVP's But in a deco already you have IPC and you you could start deploying your subnets and like Testing this concept of having parallel chains that interact with with each other with this checkpoint in protocol already implemented So this would be the best like the best way to start right now like today We are trying to push this into the falcon main net Hopefully q3 next year you should be able to deploy subnets in the falcon main net And we already have a fit a falcon improvement proposal where we explain the specification and what we are trying to push into the network soon If this is not enough for you and you want to go like really deep We also wrote a spec that will receive an update soon So here where we tried to explain low really low level for anyone that it's looking to implement the protocol the specifications for IPC again It may be a bit outdated with all of the changes that we have we had lately But we are gonna do an update soon any question that you may have again We are in slack we're in github so feel free to to ping us and there's also a paper like we We try to follow research in an academic way also So we did a position paper in a workshop so that anyone could have a high-level Overview of the system with the related work and more of an academic approach There are a lot of models here this that within so that impact the implementation of IPC and one of the key things that we're focusing right now is that as much as Marco mentioned We are trying to have a test net soon so that any user can start thinking about use cases and Like we can stress this testing this idea and see the kind of new use cases that from the web to world that we can bring To the web free before we made it to main net. So by the end of this year You should be able to start deploying FVM five conventional machine applications and solidity contracts in this Space net with a fast consensus so that you can start testing these ideas and by Q1 we should be able you should be able as a user to deploy your own subnets and Have what we have today in a deco as a more product in a more prototype Level I think that one is already here and he's gonna talk about use cases. So I'm gonna go fast over these And Yeah, so already mentioned this if you want to test IPC today You have a deco, but if you can wait a few months, you will have space net as a test net To start testing all of the use cases that one is gonna talk about I was planning to do a demo But I don't have my computer so we can do a demo in a breakout Afterwards, I can show you how to install a deco and like how to use it But I'm gonna use this time as we were running a bit late I'm gonna use this time for any question or discussions that you may have right now. Thank you very much Okay, any question I Don't see so, please Just pick up hello, thank you for talk and for the presentation in the beginning you told about partition tolerance and that like kind of competitive advantage and Mentioned that like for example polka. That doesn't have it. May you please explain how like really partition tolerance like is Like in place because like it's not super clear to be honest Yeah, okay, so that the the keys here isn't the checkpoint in protocol if we have so if you have for instance these Architecture where you have like root T01 and he's disconnected from the root net As long as the validators and like the nodes that are part of these subnet are able to still Run the consensus they can still operate with each other Of course, they won't be able to propagate information to each other But they will be able to Advancing their chain keep doing their stuff between them and batch this checkpoint. So the the How it works is that we keep advancing on our chain We keep doing our checkpoints But as we are partitioned we cannot propagate it up to the root net So that propagates further to the rest of the system the moment we recover the the connection We batch these checkpoints send them up and from there on like all of the information that was pending will be propagated to the rest of the system Okay, and so If there's like conflicts between these partitions, how do they how they resolved after the connection is restored, right? so That's a great question and We would have to to figure it out, but like there cannot be conflicts at this point But this is definition of partition tolerance Sure, but no they cannot be because you don't you cannot interact with the rest of the state You only interact with your own state and you're batching Transactions, it's like the actor model, right? You have it's exactly the actor model where you have an outbox and the next subnet will have an inbox I'm just when I part when I'm partitioned what happens is that I will Increase my outbooks my outbox and then eventually when I have a connection again I will start sending messages and there there's an inbox actually in how it's implemented this in the other subnet it's The first team first come first served so I saw I'm only interacting with my own state That it's limited the amount of conflicts that I can have I mean if I'm really relying and or I'm touching states somewhere else if I Arrive late. That's it. I mean my message. It's just need to clarify a little bit more. So basically After the connection that is stored You validate which if there's conflict you validate which was the first in which partition And you take it as a source of truth and the others what they do the do they roll back the state of all the partitions So actually how it works is that? My outbox go out and in order for my message to get in the next subnet it has to go through the committee so through the consensus engine and is the consensus engine the one that chooses the There's conflict or not So if your message is touching a state that it's completely outdated it will be rejected and not accept the transaction Okay, but how do you validate the time of to checkpoint because each subnet can fake attack time of checkpoint No, no, no what you have is that that you have an order a checkpointing order in your local subnet And this is what you propagate up is with a unique nonce and like a total order that you ordered already in your subnet This is propagated up and then the moment is propagated up the one so it's the consensus engine I mean you have only your local view so the parent we only see the local view the It will see the order within your own checkpoints and then The checkpoints that are coming from other children and they process it in parallel if there's conflict in one of the eight of them Your set it's it's there are unique nonsense between all of So it's in the order of the consensus engine accepting and validating the transaction of propagating the checkpoint up I don't know if this makes sense Yeah, kind of is it's the last question. It's a checkpoints deterministic or no, they're deterministic. Yeah, okay Thank you. Thank you. All right. There's another question right there Thank you. So I wanted to ask a couple of questions about the hierarchical design. So I guess If you think about the setups So you do envisage some sort of relationship between the parent and child note sets or some form of like shared security like it's Suggested in in cosmos to polka dot has an ocean of shared security as well Are these things entirely up to sort of the definer of these things, right? So that's sort of one question the second question is about The connection potentially between you know the fee structure So can you have something that's an expensive chain? That's a child of Tube chain or the other way around doing this interesting because I mean these designs. I mean Well, the last question specifically does come up on these designs quite a lot. Yeah, and it's a really good question So for the first one we I mean the only requirement is that you should be able to sync with the parent So it's up to you to choose the parent I mean we if you go to a subnet a child subnet that has a security Which is weak and doesn't have their kind of security guarantees It's up to you it's like an NLC and actually something that I went really fast through the IP the IPC gateway Requires a minimum collateral that each subnet can choose which one it is and you keep it keep tracks of the circulating Supply and the collateral that validators have put there and that's of course is not like Absolute truth, but it gives you an indication of what is the stake that the validators There's half in the in the network because this in subnet We also have fraud proof so you can implement fraud proofs and you can slash the collateral of that Gateway, so that's the only thing that so we have some knobs that you can fine-tune for your use case But we don't force anything like you need some collateral and and you have a Metric to know like how good or bad that subnet is but it's on you how you interact with it Does this answer your question? I think so I mean it's interesting question about what the steady state might become sort of comes up and DPUS systems for example quite a lot Yeah, similar social sort of interactions if you will and in terms of the fee structure the second part Yeah, so for the fee structure, it's a really good question We want to so at some point we were thinking that we want even subnets that are free That's okay with the validators, but of course this we have this checkpoint in fee So you would have to pay fees in the rootnet in order to checkpoint to the rootnet the same for your parents and so on and We actually we don't have anything published yet But we have a crypto icon Analysis that the Crypto icon lab at protocol labs helped us helped us do and what we realized is that the only way that you can fine-tune like the demand So actually this is driven by demand so in the end you will end up having a more subnet format or deeper levels according to the demand that you have and the key Tweaking point is not actually the fees because like actually a single account like this as a pair of keys Can be used to transact in all of the subnets So we don't touch that the semantics are the same in all of the subnets right now They are a PLD based blockchains and we use the same Like semantics and structure But if you want to influence how cheap or expensive or or you can you want to improve demand What you can play with is the checkpoint in period, right? So these will make So if I want I don't want checkpoint like check till child subnets What actually I'm gonna fine-tune is not the but like passing by Messages, but actually the checkpointing fee I'm gonna put a really high checkpointing fee Because I don't want anyone to be checkpointing to me I just want to be the source of transactions and you can play with this to influence like from your point down Of course, you can only influence your point down But from your point down what what is the actual architecture that you want? So it's kind of user-driven Because like you have all of these knobs that would allow you to I mean that we really don't know what is this gonna Yeah, so you have some control mechanisms I guess it's not obvious how this doesn't become a race to the bottom, but that's a longer question So yeah, one of the reasons for this space net is exactly this like realize how people will use this so that we can Before we go to my net we can realize what is what we need to actually like fine-tune and Improve in the design because our assumption is that maybe the first layer as you have to go to root net and root that may potentially have more fees We will have just one level and that would be enough But maybe we realize that we have more than three levels So we really don't know how people will use it because this is really demand driven And that's why we want to have a test net as soon as possible on board applications