 So hello, my name is Andreas Penskover, I'm a researcher at the IOTA Foundation and I'll be talking about parasagent detection in the IOTA 1.0 protocol. So to give some context, the IOTA is an open source permissionless DLT, which aims to become the backbone of IOT. So in order to facilitate this, we require to enable secure data and value transfer, including microtransactions. To enable microtransactions, we have to be, well, or we aim to be fee less. So this excludes to have minus and so the security in this case is then actually performed by the transaction issuers and the appendance and integration of the transaction also happens through the transaction issuers. I'll come back to that in a minute. Then the IOTA protocol is actually going through several stages at the moment. The version 1.0 is the one that I will be focusing on in this talk in particular. In this version, the network is secured through the proof of work that is performed by appending the transactions and it requires that a majority of the transaction issuers are on this. In addition to bootstrap the protocol, the IOTA foundation is also driving a note that is issuing milestones at regular intervals and transactions only considered to be final after a milestone. In the version 1.5, which is the one that is currently in progress, there are several modifications and improvements to the protocol, such as like new tip selection mechanisms, auto-peering, new TXO, etc. Then in parallel, in order to get rid of this note, there is a code side upgrade, which means that we disabled the coordinator and introduced like a new voting protocol, new rate congestion mechanisms, etc. So in this talk I will be focusing on the 1.0 protocol in order, because one of the attacks that can be performed on that is a parasite chain, an attack which double spends funds. This has been like the risk for this has been reduced in the 1.5 and 2.0 protocol, or in the 2.0 it's actually not possible anymore. But so what this the core element of this detection mechanism can be still also applied like to measure the health of the tangle or the data structure of the IOTA. And so like we can still use this method as well for the later versions. So where are we along this path? So the 1.0 protocol is basically concluded and it has been taken over by the work on the 1.5 on the Chrysalis version. And in parallel there's a test network running on the code side project as well. Then, so what is the underlying data structure that is used in the IOTA. So instead of like a blockchain, there is the employer doc and directed basically graph and as said the transaction issues directly attached the transactions to this graph by approving to former but non-approved transactions also called TIPS. And so the graph grows then into the future and the TIPS obtains a certain number of approvers and this exponentially grows into the past. So this is an animation of like how this looks on the mainnet currently. So you have like this incoming transactions on the top and transactions that are further down do not get more approvers but the weight that is put on top by the TIPS is being increasingly built on top of them and they get basically buried under the proof of work. So now in this protocol we use three different, so there's possibility for like different TIPS selection algorithms because the nodes are free to choose the TIPS selection algorithm. I will focus here on the uniform random TIPS selection and then two types of random walks. The unbiased and the biased one. The unbiased random, the uniform random TIPS selection is basically where a node just selects one of the unapproved transactions or TIPS at random. And in the unbiased random walk, the node starts a random walk for in the past of this tangle or this tag. And at each step it chooses one of the children at random till it arrives at one of the TIPS and it selects that for approval. Now these two mechanisms have a disadvantage which is that they do not penalize if a node issuer issues a transaction that just approves an old transaction. Because by if the node just approves old transactions, it does not actually add to the security of the ledger. So we want to penalize this behavior and you can do this by biasing this random walk, such that like the walk walks more towards like transactions that have more proof of work on top of them. So to do so there's like a parameter alpha that is quite delicate to choose. Yeah, as shown here in this probability transition. So it's quite important to choose this alpha value correct if you choose it too small you basically just end up with something similar to the to the uniform random tip selection. So you have like this lazy tip selection problem again or you're familiar with attacks. If you choose it too high you risk that you just choose to hide the trajectory of highway and you often transactions, which lowers the maximum throughput in the system because you have to reattach or promote transactions. Now, the bias random walk is computationally much more heavy. This is because you have to perform algorithms to count how much weight is pulled on top of a transaction. But it does prevent the lazy tip selection. In addition, there can be perform the double spend attack in this in this stock system on and this happens in the following way so you have a an attacker places a transaction to emerge and in the in the tunnel and waits till the the merchant accept these funds in parallel he minds secretly like a chain in parallel that he only reveals once the spend has been accepted and then he hopes that this parasite chain. Tangle is then overtaking the main tunnel and this would mean that all of this transactions in the center he would be orphaned and this becomes the main tunnel here. This can happen for all of those three tip selections. And if you are in the uniform random one you just create many tips in the ambiance random walk you just create many links to the past. So, they're not very resilient to this type of attack with the bias random walk. The attacker has to actually outperform or almost outperform the main network temporarily in order to like overtake the overtake the main tunnel, the honest part of the tunnel. This is also in this terms, like more secure. Nevertheless, you so the attacker could have a chance to like perform this attack. And what we want to do is, we want to identify this parasite chain and and we can then take countermeasures to prevent it from taking over the main tunnel. So, how can we do this. It's basically this parasite chain has a very different structure to the main tunnel. In particular, if the attacker wants to have a very efficient parasite chain, he needs to create a lot of links to the main tunnel. And as you can see here in this very simple parasite chain, each transaction here has only one approver. Now this is very different to the main tunnel where you can actually have transactions have a very high number of approvers. And so what we can do is we can like create a metric that measures how likely it is that transaction has a given number of approvers. So here you have like three approvers to one and it varies, whereas in the parasite chain it would not. So we can create a distance metric that measures the distance of like how distance this walk as we perform the walk is from like a walk that we would perform in the main tunnel. Now, the model is based on that the transactions that are incoming or coming in randomly and are independent of each other for a personal process. And you derive then that there's a the number of tips is proportional to the transaction rate. And we find then that for a given transaction, this, this number of approvers is also personal distributed. We're like a gift to term here with like it's like an integral form that depends on the on the probability that certain transaction is being picked while it is a tip. And this number of approvers for a given transaction we can derive the probability distribution. And as, and we show here like on the right, that for a large range of transaction rates. We find that the simulation is actually agreeing very well with the model. So we cannot perform this so this was for the. I mentioned this this is for the uniform random tip selection. So this is the random selection. This is strongly connected to the ambiance random walk. But the situation is a bit more complicated here so with the ambiance random walk, we have different exit probabilities. So they're not the normalized exit probabilities not one anymore as it would be with the uniform random tip selection, but it varies. And what we can do is we can sort these exit probabilities by the least likely to most likely probability. And we derived an exit probability distribution. Now, in the Iota 1.0 protocol, the values are such that at the moment that the bias random walk is very similar to the ambiance random walk so we can model this to similarly. So we then can use this exit probability and use it to derive a probability distribution for the ambiance random walk. And as you can see it's like tightly connected to the uniform random tip selection. It's like linear to it does some integral term, and we can simplify this integral term. So we have a linear approach instead, which still works very well in our in our tests. And again, we can find that the probability distribution is very similar to what we expect from our simulations. We then plug this probability distribution, this metric of how on average, the number of approvers looks like into a random walk that we perform. So basically, we perform like run a random walk through the tunnel to select the tip. And as we go along it, we remember and count how many approvers we have accounted at each given transaction. And from this we derive a probability distribution of like, or histogram of like how many, how many transaction you found, and you compare this distribution that you found with the reference distribution that is given through this model. We then a distance, and, and this distance of course varies as because of stochastic reasons so you have then you can have different distances of course but and just depend on the sample size s. So for example for the sample size s equals to 10, this distance can vary a lot, but for a higher sample rate of like 100, you actually get a very close distance already. So these were like all taken from the, so these were all taken from the main tunnel now. And here is like where the situation would be with a parasite chain. So with like a very simple parasite chain, which would be the most efficient case, you actually can very easily detect that it has a very large distance. The attacker can hide this a little bit by using some of the transactions within the parasite chain to create a distribution that's more similar to the one in the main tunnel. But he loses a lot of efficiency of the parasite chain, because he has to invest this proof of work to links within the parasite chain rather than like linking to the main tunnel. So you can decrease actually attack by quite a bit. So what can you actually do once you have detected a parasite chain. So there's several approaches that we can take. One is for example described by Ferraro King and Shorten, where you restart, or you start the random walk again from the from the from where he started initially, but with your first step being a more heavy walk. Now this with this more heavy work, you avoid going along something that is something that is like a much lighter weight initially which would be the parasite chain once it's revealed. And so you avoid this and with the second tip you can simply avoid anything that disagrees with the first walk. So then you basically avoid going down this path. However, then you only use one of those two tips that you selected to actually secure the ledger in terms of like collecting all of the transactions whereas the first one is just securing the ledger it does not actually add many, it does not include many lightweight transactions like this. A different approach would be to reverse several steps back to exit the parasite chain, or you can also probabilistically like sometimes step backwards and forward. This would also like increase the chance to like exit this parasite chain. You can also like certain improvements. For example, as I said already like it's more difficult for a for an attacker to include high numbers of approvers in the parasite chain, so you can reward having high numbers of approvers by changing your, your measured, your, your distance metric to this queue here. You can also perform a future cone detection, but however dislike requires like another walk algorithm that is fairly expensive so it's only worth like doing that occasionally and maybe once you have detected a child that might be a parasite chain, but you're not searching to do so. So these are the measurements. Yeah. And so, yeah, so right now at the end of my talk. Thank you very much for listening.