 My name is Michael Verland, I'm on the product team at Altyn, having a last date with DevCon, thanks for showing up for the late talk. I'm super excited to talk about this. I think it's one of the most frustrating things for a lot of smart contract developers and a lot of people building on Ethereum. It seems super simple to be on set, but it's really not the case. So hopefully we'll talk through today. That kind of announces what they are, the problems they cause, and then a few ways we can start to handle them and start to solve those frustrations. Before we get started, as you don't know, no worries if you don't, we've been very quiet. Building things for about 10 years in the blockchain space, with Nokia marketing. We've been powering blockchain infrastructure for a bunch of awesome companies like Auger, ZeroX, CryptoKitties. Building developer tools on top of that. For example, we want to help developers focus on the things that matter. They only have their IP growing their user bases. So I've really been working, lucky enough to work with some awesome folks and doing that. Now, let's start from the nonsense. Disclaimer, there will be a lot of nonsense-based funds in this presentation. So what is this nonsense? When we talk about Ethereum nonsense, there are really two things we're talking about. My address, this is the way they win block awards, incrementing this nonsense to win the cryptographic puzzle. It's kind of a proof-or-work concept I'm sure most of you are familiar with. The other thing is for applications for end users, when you're submitting transactions, we need to submit them with an ounce. It's basically a counter of the number of transactions that are confirmed from the address that you're submitting them from. It's basically the way that you're able to send rights to the network, the application side, and the user side. So that's the limit again. So you're going to start with four simple word nonces. If you're starting from scratch, super easy, your nonces zero. That's great, really straightforward. For men, it doesn't get too much more difficult. If you just increment by one, it's a counter. Straightforward, you all know what I'm talking about. So the interesting thing is what happens if things go wrong. So if your nonces too low, you know right away it's not a big deal. It'll say nonce too low, so you can pretty easily increment or submit. What's interesting is if your nonces too high, your transaction will basically sit around in the men pool. It won't get mined. It'll sit there until basically your nonce counter catches up. Which in a lot of cases is hard to do, because you as a human are not sitting there looking at the nonces that are happening. So your application tends to just stall. The other problem is, sorry, so we have two main purposes for nonces. You know, digging into why they exist in the first place. One is for ordering transactions. The other is to prevent certain kinds of attacks. So on the ordering side, a simple example, let's say you have a smart contract, building out a decentralized social network. You don't be able to do things like create users, have them friend people, decommission accounts people on. On the left is what's intended. The user creates a new account. They friend somebody, sometime later on they delete their account. On the right is kind of what can happen if you don't have proper ordering. And really, nonces are the way that this is ensured in the Ethereum world. And as you imagine, the right side, everything's going to fail. You're going to end up with outright failures for one, two, number three, the user ends up running out. So nonces are really important here. Then there's the attack side. So simple payment example, with nonces, in the Alistratus, sorry, without nonces, if Alistratus came out of one of these, Bob could basically grab that transaction and send it as many times as he wants. Because there's nothing to distinguish the legitimate transaction from the bad one. And so the outcome here is Bob, he has something called a replay attack. He basically just repeat this transaction over and over until Alistratus has more money and Bob is profited massively. With nonces, Alistratus submits that same original transaction with nonces, let's say number seven. And it gets Alistratus's actual transaction and the counterfeit one. It doesn't really matter which one is mine. Both of them will resolve for the same thing, which is that Bob gets money from Alistratus. But when the second one is attempted to be mined, it sees that the nonce is still seven, it expects the nonce to be eight now, so that transaction fails, and you can't repeat this malicious attack over and over. So all these things lead us to whatever it does, the non-secret formula to go with nonces. So you start with the question, is this your first nonce? Okay, so if your nonce is zero, you're going to go, no problems there. If you're keeping track of your nonce, if you know how many transactions you've sent, you're also going to go. So if you send transactions, awesome, your nonce's in. If not, no worries, there's a backup plan. You can call something like getTransactionCountPending, the result is your nonce. Super simple, rinse or repeat, your application is well functioning, you're off and profiting. Let's go in on one of these attack steps. So number two, supposed to be your nonce, that's what it means. So you should have that nonce. Turns out it's not actually going to be that all the time. Probably isn't. A lot of times it's going to fail on you. The reason here is that most applications are sending multiple transactions at a time, so they intend for multiple transactions to appear in a single block. When you do that, you're submitting them with incrementing nonces. Let's say from zero to n in this case. So the question is what happens if one of those nonces fails? So the second transaction with nonce1. We got one of those earlier when nonces have, when there's a transaction with a nonce that's too high, it hangs. And since there's no transaction that's succeeded with nonce1 at this point, all of your other transactions are hanging. What do you question by transaction failure? So there are a couple of ways this can happen. Some that are outright failures and some that are not. The most common way this happens is also going to put a bunch of transactions. One won't hide a cast, for instance. So it's not against broadcast. So failure in this case means failure to be properly broadcast combined, or in some cases more outright failures. So as you remember from pending, so no worries. It's failed. We have another plan. Problem is this also fails a huge chunk of the time for a completely different reason. So this is more of an architectural reason. Most apps who are building on Ethereum need to scale beyond a single node. We're running multiple nodes. In the web server world, you use a load balancer nice and straightforward. Turns out when you do that with Ethereum, things start to break pretty quickly. A lot of people we talk to when they're building out their in-house infrastructure, this is exactly what they do. A lot of third-party APIs build things in this way. It makes managing nonces much, much harder. So a quick example here. We're firing off a bunch of transactions. There's getting routed to one of the many nodes behind our load balancer, to update my nodes. This also gets routed to only one of the three nodes. And I get three different nonces depending on where exactly my query gets routed to. So there's this kind of inconsistency problem. The one consistent thing here is that none of these nonces are correct. None should be free. So in all of these cases, you're actually failing. This is a bit of a race condition. So eventually these transactions will propagate to the other nodes behind this load balancer. So if you wait, retry, eventually it might work, so that's one way of handling this. But it's not super well functioning for applications that have any kind of likelihood they can see concerns. So then there's another concern here that makes this even more difficult to deal with. Getting parity actually defines handling when they do. It's usually after probably a week of really... So when they talk about pending, it's basically anything you submit a transaction, it hasn't been mined yet, it's considered pending. With parity, there's actually this idea of a virtual pending block. So it's things that the node thinks will be mined in the next block on the network. So it's only a subset of the things that get considered pending. Which means that you might actually end up with the wrong node, the wrong goss, with parity when you would have otherwise gotten the red mark from the gap. So if we look at our example here, if we're parity instead, you get zero in all cases. Okay. There are other things that are going on here that make this, again, more complicated. Things like race conditions. There's no big show on parity where if you submit a transaction and all expanse or get a transaction counter very quickly, you don't actually break it off. So things are constantly happening. It's a pretty complicated problem. So things go apart and eventually get fixed. So we got a few points of contention. A few steps to the theoretical but only sometimes. But actually, this is the one case. The only nonce you can ever be really confident about on a time is with non-zero. You can start out confidently. It's only from there that it gets complicated. But there are a lot of things we talked about already. There's also problems with multiple services managing the same address. When nodes restart, the mempool can get cleared, which can affect nonces. Things have a huge impact on this. So there's a lot to worry about as a developer when it comes to this simple algorithm that seems like it would be really easy to get started with. So what do we do? How do we actually start to handle this problem? One thing is the way for E2.0. I don't think that's the right solution. I'm guessing a lot of people in this room have applications they're building right now. They have users. They need a solution for this in the short term. And waiting for... So let's start on the road to dominance. In terms of infrastructure, it doesn't seem like an API call like this or the traditional ways of handling this should depend on infrastructure, but they actually do. So as you know, is your in-house system load balancing nodes is the API you're using doing that? If it is, you can still make this work. It's just going to be a little bit harder and you need to have this in the back of your mind when you're building things out, considering how to handle nonces. The other thing is, do you have access to pending state? So nonces are effectively the way to see what's pending, what's dropped, all these kind of things. It's going to be really, really helpful. Some services don't like you to do that. If you don't know this, you probably can. So you're in a good shape. Both of them are using Parity. It's a super quick switch that you use Parity next month instead of get transaction pending. The Hayes like you would expect it to. So it will work in the same way that you get a pending transaction tool. So number two is the other transactions. This is basically an understanding of your new space. So depending on what you're doing the number of transactions, ordering might matter, the number of transactions, transaction throughput might matter, latency, all these kinds of things. So you need to understand your new space to know how you're going to approach the nonces. And then one kind of thing I had was consider this kind of thing earlier on. It's more contract development. There are trade-offs in doing this. I knew a lot of people don't end up getting nonce problems until things are deployed. They have users, users start to complain or their own developers do. You do these problems early and you'll have a better time later on. Cool, so as far as actual solutions, number one is maintaining a nonce state is super, super helpful. That way you can minimize your dependency on these API calls that tend to have their own set of problems. New store nonces is a single account on the counter putting in something like Redis. All of your services can access it, increments it. You're doing pretty well. And then if you need to, when you're restoring things, you can use those API calls to kind of see things to begin with. The next is you can use no-op fillers. So this is a way of handling the kind of like hanging transactions problem. So let's say we submit five transactions all at once with incrementing nonces. Things are going well initially. They're getting mined successfully and then eventually one fails. Like we talked about before, the next two would hang. What we can do is basically create what's called a no-op, a zero-e transfer to our own address, submit that to the transaction that failed. That's a really quick way of jump-starting the system. Again, this is pretty use case dependent because it means that your transactions can't be dependent on ordering like we talked about earlier. But if you don't have that requirement, that's a really solid way to keep things kind of well functioning. So other things, just quickly run down the list since this is a 20-minute talk. Meta transactions, I don't have a time to experience with what I've heard. Ordering is really important for you. You can basically batch a bunch of operations into a single transaction and have a smart contract kind of distribute them effectively. Using one transaction per address per block, this is basically the idea of like you submit one transaction and you wait for it to be mined until you submit another transaction. That's not going to work for a lot of people because it is very slow, but as you care about minimizing failures much more than minimizing latency so one of the things that gets complicated here is a bunch of services using the same address which are all connecting nonsense which makes this entire world much more complicated to deal with. If you isolate each service to use its own address you can kind of make life much more much easier for yourself and prevent things from stomping on each other. And along the resets on us we're super, super happy to help. This is something we've helped with on like a use-basic or something basis for a lot of our users. So let us know if you're running into those problems or if you haven't talked through a lot of the best cases we've talked through. And then finally, open source open source. Talk to a lot of people this week that are tackling exactly this problem with some really cool output. Some guys at Bloom gave us a talk about it earlier. Really cool stuff. Intribute, pay attention, and hopefully we can all solve these problems together. Thanks.