Welcome to the E2 Q&A session. What we're going to do is I'm going to ask some very, very basic questions just to get you all up to speed. And then I'm going to open the microphone to the crowd. Just a few things. So the whole thing about validator rewards and so on, I don't know if you want to dig into it. Otherwise, I think it's consensus that we can skip those questions. Makes sense? Yeah? Cool. All right, so maybe let's start with Joe. Can you give us an update over the interlocking and what you achieve and what that exactly means? So we had this lock-in is what we called it. It's kind of a workshop for a week out in Muscova, Canada. I guess we got somebody from Muscova here. Nice. All right, so basically the idea was that we basically trap all the developers in this place and make them join our E2 cult. And then we'll work on our clients together and reduce the round trip time for communication for everybody on getting their clients to interrupt. Interrupt is essentially being able to talk over LibP2P to the individual clients and gossip at the stations and block proposals with validators kind of like shared among the individual clients. Everything that you need without syncing. And so we were expecting, I think, eight clients came, seven got to interrupt. And that was really exciting. I think we thought that there would probably only be three or four that would achieve interop in that time, which means that all the individual clients are really doing a great job. So I think that that gives us more higher probability that we'll make some early Q1. Don't quote that. But that's kind of like the idea right now is where people are saying when they want to see a beacon chain up. And so I think there's higher probability of that now. So just to give an update, does everyone know what ETH2 is formed by? How many clients do we have? And all of that, I'm asking the crowd. Because otherwise, we should give a primer. OK, apparently everyone knows. All right, so I don't know. So we have a couple of the clients here. We have NIM booths. We have a lighthouse. I just, like, I can't. What? The ETH2 specification. The ETH2 specification team. We have a load star as well. And we have anyone else? Ardynis? Oh, sorry. Yeah. Trinity. OK. Quilt for prototyping phase one and two. Quilt is here. They're prototyping phase one and two. On Lighthouse. All right. Which of the clients is the one that's most advanced? Loadstar does a really good job at fuzzy tests and other clients. We blow them up. Like, yeah. Lighthouse thought they weren't going to panic. We made them panic. They fixed it. We made them panic again. Loadstar best client of all time? Oh, no. That's what we got? Best in the browser. All right. Do the existing clients here want to give a really quick update? Maybe we start with, OK, we don't start with you, Yasek. Yeah, Nimbus. First of all, yeah, thanks to Consensus and the organizers of the interop. It was really, really, really good to get together there. Work out a lot of the practical little details that have to be worked out when you're trying to make two pieces of software work. You'd think that it's easy like there's a spec. Everybody just writes the code and then puts it up and it works. That's obviously not the way it works. We have a pretty complex product coming out. And there are very many basic building blocks that have to fall into place. Like, that's the networking. That's the cryptography. That's the spec itself. And I think really valuable was finding out and using each other's clients as stress tests as a first sort of fast testing platform so that we could feel out where the other clients have put their effort the most. And then that's how we could improve our own client to sort of match that level. So I think interop was great for this. We found lots of bugs, lots of issues, lots of places where the thinking was not consistent between the clients. And that was sorted out during that interop. I mean, there was a lead up to the interop where clients were sort of paring off and trying to solve some of the initial things to make it smooth, right? So that's probably why we saw so many successes right on the spot as well. Thank you. Artemis? So after interop, we ripped out our Rust implementation of libp2p. We're the Java client. So we went for the JVM libp2p that was built by Harmony. And we put that in. And now we're kind of working on some sync issues. And some implementation issues to kind of get ready. We're turning our team over to start working on a sharding client. We're leaving our beacon chain client with a production team who's going to kind of get more hard in for production. And yeah, that's kind of where we are. We're going to work on a new sharding client that's going to be built in Kotlin. Just super set of Java and also compiles to machine code. Loadstar? Yeah, after interop, we started. We kind of broke into several different subteams. We're working on getting loadstar kind of productionized. We have a lot of optimization to do to really get to this production level that Danny was talking about. And we also were kind of looking ahead at light client work. So we started to prototype some of that work out. And we're hopefully going to start contributing back to the spec a little bit. Thank you. Lighthouse. We're going well. Our main focus at the moment is to target feature completeness. So phase 0 feature completeness. We're getting quite close. We're just sort of polishing off the integration to F1 to the deposit contract. We're also working on some slashing protection for validators. So this is kind of the idea of feature complete being that we can run the protocol. We have everything we need to run. And we can run off the deposit contract. But not necessarily can we run for, say, a year and use reasonable disk usage. So that's something we're working on now is trying to figure out how to optimize our database storage so that we can run for a long time. Yeah, so I think the next thing for us is we really need to start testing more public test nets. We need to get one of our own public test nets up. And we also need to start doing test nets with other clients using the F1 chain as the source of deposits. So we can test this dynamic validator set because this is the thing that we didn't test at interop. So yeah, that's us. And we're also really trying to help foster the cool team to make sure that they can keep researching the next phases whilst still delivering phase zero. Yeah, so Trinity was an interop. We had a lot of fun working with everyone. Since then, we've been just sort of merging in all the things we found there, nothing major, but just a lot of tiny little things, as I'm sure other people found. The big thing for us will be performance. So Trinity is a client written in Python. So while it's great in terms of being readable and very approachable and accessible, we definitely have to deal with sort of this performance penalty we accept by choice. So that'll be a lot of our work moving forward for the next couple of months is making really fast interpreter code. Cool, thank you. I am losing my voice, so excuse me. So the Quilt team has been focused on doing research around phase two, building on execution environments and doing some early prototypes on basically the stateless paradigm. So we are already building execution environments that are operating with in a stateless way. And we built a simulation within Lighthouse's kind of base code base where we now have shard chains or multiple shard chains interacting with the beacon chain. And we're able to actually run the state execution on that as well and run these execution environments on it as well. And so we have been, I guess kind of what we're doing next is expanding that to include more simulations of what the state market might look like, advancing on what may be EEs for some of those contract frameworks as well. Yeah. And do you guys want to give an update? Yeah, we're working on all sorts of things. Adding, add some additional tests to phase zero. Justin Drake did some excellent work making phase one look really nice and easy to reason about and elegant. A lot of research and thought and conversations around phase two. And more recently, some conversations around potential alternate structures with phase one that might allow more rapid cross-linking and better communication between shards. At the same time, working on some standards, helping drive the standards process on BLS. Carl's been looking into key store formats, pushing on the deposit contract stuff, which is formally verified and ready, but we're waiting on the BLS standardization to launch that. And opening up the conversations around the coming public test nets with the clients and always kind of providing support and answering questions on the client side. So just keeping everything moving forward. Yeah, and I've been coming up with this and alternate structures for faster cross-linking that Danny mentioned that we should have some information out about maybe very soon. Also, data availability, there's been a lot of progress on different kinds of data availability proving mechanisms. There was also that interesting coded merkle tree paper from a couple of days ago that lets you do erase your coded roots with much smaller fraud proofs, which is also really nice. Also, we're thinking about a fee market simplification and coming up with ways to deal with edge cases and reel your markets and all of those issues. I guess I've been thinking about optional upgrades. One of them is the idea of a secret leader election. So right now, beacon proposers and shop proposers they're known in advance that they're going to create a block and then these leader based systems suffer from denial of service attack surface. And so what if we can have a system where you don't know ahead of time who will be creating the next block that would be much more resilient. Another kind of optional security upgrade that I've been working on for some time and it's still ongoing and we're making lots of progress is the VDF project to have unbiased randomness. And I guess I've also been thinking maybe a decade into the future on E3 and how to make a firm quantum secure. At least 10 years, I'd say. Dan Bonesa's 30. But Dan also said, don't quote me on that. All right, I'm going to open up now to questions from the audience. Who want to go first? You mentioned you're doing a lot of work on fee markets. One thing that I would love to see is a bit of a high level abstraction so that you can specify how fast you want a transaction to happen. Like I want it to happen in a minute or five minutes or an hour or I don't care. And then it bills you like how much it should the market rate would be for that. Like you could pay more and then it would refund you the difference because right now it's guesswork. Like trying to guess the right amount of gas. I think this is the sort of problem that EIPA 1559 is meant to basically eliminate. Like users would in the normal case see their transactions just included immediately. Anyone else? Questions? Okay, we have cable so can you come over please? My name's Chi, I actually have questions. So the number of straws I'm trying to understand will start with 1024. So I'm wondering why choose this number? Especially together with a large number of validators. There will be significant costs or number of costs especially at the starting of this or two. Is there any concern that maybe we may not be able to reach so many nodes of validators at the beginning? And so this is one of the things that this kind of faster cross linking proposal might actually end up changing potentially. But I think in general the justification here is that we're trying to kind of, like there's two different kind of constraints that we have. One of the constraints is the load on the beacon chain. So we want the higher the shard count the more scalability but on the other hand the higher the shard count the more cross links on the beacon chain and the more expensive the beacon chain will be to process. And the other constraints that we have is just the higher the total throughput of the system the higher the harder it is to be a block explorer, the higher the risk that some historical data will eventually just end up being forgotten completely and so forth. So the scalability that we're expecting, like the data throughput that we're expecting is a number though. We've quoted numbers between one to 10 megabytes per second and that seems kind of to be close to the upper limit of what people are fine with so far. And for the load on the beacon chain like we've done numbers and it seems like beacon chain blocks can in the worst case be verified in like about a second now is it? So once again it's like that much but not more sort of thing. Yeah I think there was like four million validators were starting to encroach over a second so that's way above what we'll get. Yeah and like I personally want to be conservative with beacon chain numbers so like I want to I personally really want to avoid the mistake that we made of like an ETH one where like because the chain was heavy like so few people wants to run a node like I would prefer a beacon chain node to be just a thing that you would run by default rather than like running only when you need it and that does necessitate kind of fairly like stringent performance requirements. Yeah I agree, things are the faster how it does too. I mean on the concern that there won't be enough validators to start with we're essentially handling that by only doing the genesis once we have sufficient validators so the current numbers are 65,000 validators two million ETH. Another idea that we're considering is that even if we go for a thousand shards in the very long term we could slowly enable them, ratchet it up so start maybe with 64 shards and then over time have it increased because at the very beginning there's gonna be very little activity and it might be worth using less shards. Yeah speaking of block times or block processing times it's important to remember there are cases where we have to process blocks which are not necessarily good ones that might be spammed, might be maliciously constructed that takes time away so we need to have a little bit of a buffer and that also affects the way that messages propagate in the network so we're using an epidemic network which basically means that all the data is replicated all over the network and the longer it takes to process or the longer a full block processing takes the less validation we can do ahead of time meaning that the more risk there is that the data that the network will be flooded by bad data or that it will be slow, either of those two right so there's also that argument that if we can do more good validation upfront and still maintain low latencies we also gain in other parts of the system as a whole. Yeah so I'm wondering what the plan is in general terms for handling of ERC-20 assets in particular transfer functions as a developer it's somewhat difficult from user experience standpoint and there's been many proposals ERC-223 for instance as an interesting proposal but as we transition to E2.9 I'm curious what the general plan is for handling those assets because there's just hundreds of them just migrating them to 223s and sort of feasible curious your thoughts? So kind of unrelated to the whole transfer from thing which I agree needs to be reformed somehow another issue like another reason why things need to be reformed anyway is that assets are probably the major category of application that we expect like any particular token will need to be accessible in all shards like most applications like realistically unless you're in the top 10 you could just live inside of one shard and you could expect people to just move their points to your shard, do stuff inside of your application and then go somewhere else but tokens need to be able to be moved around everywhere and so the idea of a token as being a balance of one particular model with a contract is not something that can really survive and so you'd expect token holdings to themselves kind of be more like individual contracts and when that happens you pretty much it's an opportunity to kind of reform other things about how the standard works as well. Another question I had just to go back to Justin you just a minute ago mentioned that it could start with 64 shards previously I hadn't heard this so can you expand on that a little bit more as to how that could happen because previously the response was that you'd be under utilizing it but is that really the only consideration that you'd be under utilizing the beacon chain the throughput that's made available like why couldn't we start with a lower number and then scale up or would you have validators sitting out and not really activated? I mean the validators do all sorts of things one of them is crosslinking and so technically speaking to reduce number of shards is pretty trivial like when they do the crosslink some of these crosslinks will just be hard coded to zero and this zero hash will mean that there's no data flowing through the respective shards but you know these validators would still be providing value for example they'd be contributing towards the finality of the beacon chain and all sorts of other things I mean one good reason to start with lower shards is lower counters that maybe more network stability we wouldn't have so many shards subnets that's a nice thing also it allows for services like block explorers to give them a bit of breathing space to ramp up to bigger numbers as to how we increase to a higher number of shards we can have some sort of automatic schedule or we could kind of push this to the social consensus layer with hard folks So this is a possibility that it could start much lower? Yes and I think it's the natural thing to do I think Yeah because I've heard from many people and I'm sympathetic to the idea that block space should be economically valued or it has economic implications and it should be valued highly and if you have an overabundance of it then you end up devaluing the transactions that are contained in it I mean that's a good point if we have fewer shards it means that we can really test the new gas market with EIP 1159 which by the way is awesome it just seems to solve so many problems Hi I'm Kent, I'm the head of R&D at Shapeshift and I'd love to hear more from you Vitalik about the use of phase one in the data availability context this excites me a lot because it seems to me that a lot of the really vexing challenges with E2.0 or R&D phase two with sharded EEs and trot cross-stream communication this could effectively really give us a very nice bridge where we have layer two solutions with Starks and Snarks so kind of a two-fold question to what extent is the data availability aspect being specced out and built with those particular use cases in mind and also if you could shed some light on the big research challenges and questions as that aspect is built out Sure, so there exists the scalability solution already like Plasma Group is doing a demo of it like a severe, I think at DEF CON they call them optimistic roll-up and optimistic roll-up basically works by publishing transaction data in a very compressed form on-chain but not doing execution on-chain and optimistic, but because you avoid executing you only have a little bit of data and especially because data is very cheap relative to computation even on the ETH1 system you can achieve scalability of like 10 to 100x like the theoretical max throughput is somewhere around 3,000 TPS if everyone were to just use optimistic roll-up for moving coins around and ETH2 could potentially make optimistic roll-up even more powerful because instead of using the ETH1 chain's data store to store this data to make sure that it's available you would be storing that data on the ETH2 chain and you would basically kind of feed into the ETH1 side and merkle proofs that prove that hey, this data actually has been accepted by ETH2 and so if you imagine like even if say we reduce the shard count and even the scalability at the beginning is towards the lower end and say there's one megabyte per second of data availability then if we talk about say 20 byte transactions then that's 50,000 transactions a second that could fit inside of a roll-up and that's a system that could like the logic for kind of doing it is something that is being developed already I think the main challenge that would need to be solved is that you would need to have at least a minimal sort of fee market on the ETH2 side so that optimistic roll-up relayers would at least have the ability to kind of publish their data and that is one of the things we're actively thinking about and the other challenge is if you do want to use phase one as a data availability layer on ETH1 you need to go down the finality gadget road and expose ETH2 data ETH2 state routes to ETH1 so you can make proofs against it so depending on as we talked about in the last session depending on kind of parallel road maps and how long expected things you're going to take it may or may not be worth it Right, next question Martin Hey Martin You need to actually jump everyone Yeah, so I came a little late so I hope this question hasn't been asked if so, I'll just excuse myself but the question is around the process by which a particular execution environment is chosen for a shard if there's like some auction going on or renting that space and also what might happen if you need to change something about the execution environment like forking it or something like that So within all of the proposals we're considering so far I think blocks would have the ability to contain space for multiple execution and kind of environment spaces in them and so basically like you would expect like it's ultimately the block proposal that chooses what to include and different people would be able to bid but like you would expect at least popular execution environments to have a presence and be executed even in every slot in the shards in which they're located Yeah, so to be clear the execution environment is defined on the beacon chain and thus available on all of the shard chains and so when you make a block you're kind of signaling this block is for this execution environment and thus the data in this block or chunk of data maybe multiple is for that execution environment and so you can kind of think of say this block was for execution environment A this block was for execution environment B and the next one was for A like the actual block chain of A is like this subset of the actual shard chain and on the forking I think so the nice thing about it is you could actually define migration paths such that you could deploy a new EE and have some sort of migration from previous EE to new EE and I do expect these things to kind of emerge in a standards way kind of like in the ERC standards but I could also see that certain EE's especially like the ETH-1 EE could still maybe be subject to hard forking to upgrade and manipulate depending on the kind of social dynamic around that Yes, yes, so I'm saying that would be A like to actually change an EE would require kind of changing the actual code of the protocol in an irregular state change there are options to migrate and upgrade EE's without doing that but there it might still be like a social tool to coordinate and manipulate these things Will the EE's be permissioned or like you're not gonna so if you wanna add a new EE do you need to fork anything or can you just add new EE's? Large transaction for your deposit requirements so the beacon chain doesn't get filled up too much but like anyone would be able to do it So you're not auctioning them like some other guys and are you expecting applications some of the bigger ones to have their own EE? Possible Yeah, possible A lot of like the reasons you might have an EE like it doesn't actually make sense and it might just make sense to operate within an EE but I do funny that you asked that I have thought it could be like certainly a way to advertise like if the casino has their own EE come join us Yeah, like gaming EE I mean there's probably some data that we would wanna store that no one else wants to store Yeah, or maybe not data but more like how you optimize the structure of accessing certain things Yeah, a fraction of a second block time would be really good Yeah, I think it might be like another tier of developer that makes an EE it might be someone that's working really deeply in protocol research or like zero knowledge proof research or something they really know what they're doing and they can't do it anywhere else and then they'll go to that but then you're like kind of typical developer that's at the application layer would probably wanna stay away from it Any other question from the audience? I mean while we're waiting for a question I mean maybe to put a bit of cold water on the whole EE I mean the EE's are a beautiful piece of layer of abstraction and very useful in the context of migrating in EE for one into EE for two but there is also the possibility that EE's add extra friction between them in addition to the friction between shards and there's also the possibility that we'll have unsustainable EE's so EE's for example without a state rent similar to what we have right now in EEF-1 and if they become popular then it's all sorts of complicated questions so it is possible that at least in the short and medium term we will roll out with some sort of default and shrine EE some sort of native EEF-2 EE which just acts and behaves like somewhat like EEF-1 does today and you won't have that much room to play with in the medium term and then in the long term we open up the EE's to everyone right but how do you manage that process of opening up to everyone well that will happen under consensus layer and one day we say hey anyone can publish an EE so going back to the permissioning question maybe no one will be able to publish EE's for some time I'm not saying it will happen but it's a possibility alright questions how much thought has there been to transparent sharding where that developers don't have to figure out which shard they want to be on because if you give them that choice maybe they'll just all choose to be on the same shard I mean that's one of the really good benefits of opening up to EE's is that all this innovation on transparent sharding can be done at the application layer and us as consensus designers we don't have to bother about that and so if you're near or polka dot or whatever comes up with some cool innovation that can be integrated with fairly little friction and there's already ideas out there for using the shards as fungible data availability resource that can be used and kind of decoupling the logical centralization of the application from the underlying resource which is sharded so who decides where the application goes like does the application get to decide what shard it goes on or does it have no control over that I mean at the lower level the EE lives in the beacon chain and it's made accessible to every shard but then it becomes a question of for the dev developers how do they want to either restrict themselves to a specific shard or have some sort of virtual EE or virtual execution environment which is separate from the consensus level concept also within EE development there's a few things you can do and when this opens up as well I think there are a couple questions so one question is do you have to deploy to the beacon chain and do you also have to deploy to multiple shards or do you automatically have it available across all the shards so that's one piece but also within your execution environment you could technically build some basic level of scheduling yourself as well saying I will only operate certain certain transactions on shard five for this series of epics or shard five, six and seven for this series of epics so there's a lot of flexibility in how you can write these and how you may be able to enforce load balancing yourself just within the semantics behind an execution environment are we gonna retain the financial Lego that we've got a plug and play between composability are we losing that or compromising that with the sharding from a tooling perspective well right now you can plug compound and die together or something if you don't know, if your Lego blocks are now on different shards and they can't interop without cross shard links which might be slower and have some penalty so I think that, I mean I get the concern but I think all of the kind of DeFi integrations like for just as one example I've seen in practice I don't think any of them really break from asynchrony one of the reasons why is that half of these integrations just happen to do with like one system containing a token from another system but tokens are one thing that's like they're probably easier than anything else to move across shards you just like yank the contract over and like one Merkel branch and it's like somewhere else wherever you want it to be I think the thing that and then if you look at like even Uniswap for example it just moves tokens around you move the token to the Uniswap shard swap it, move a token somewhere else so most of the integrations do kind of work that way the ones that don't are basically the ones that involve kind of synchronously calling other applications but like even in that case a lot of the calls do tends to be asynchronous or at least would be perfectly fine if you did them in an asynchronous way so at least given the applications that we know about I think that's a kind of a smaller risk than a lot of people think I mean I could see like execution environment fragmentation being even a bigger issue than shard fragmentation if not handled correctly and it's definitely something that we're thinking very actively about how to smooth over I mean concretely it might turn out that cross-chain communication is actually faster on if two than an if one transaction if one on average is 15 seconds and two ways that we could have fast cross-shark communication is one we have this new proposal where we have cross links in every slot on the beacon chain we might have cross-chain communication in just a few slots and then the other way kind of which is generic is to use optimistic cross-links where basically you have some sort of off-chain mechanism to gauge the probability that some cross-link will eventually make it into the beacon chain and get finalized but you don't have 100% probability that will happen and then you can design your application around that and benefit from the low latency Can you do any some kind of automated garbage collection and start moving smart contracts that wanna be on the same chain together so that they're faster? So I generally think the space across interaction around multiple shards I think there should generally be a set of tooling within the HLLs or TSLs that are used so with insulidity, Viper, anything else so from a DAP developer perspective if you accept asynchronous as the basic construct of communication across shards you can have tooling that does that through message passing you could have tooling that does that through two-phase commit system if you need some type of atomic transaction you could have tooling that so I think from a DAP developer's perspective you're going to have more tooling in these languages that you would go ahead and utilize for the problem that you need Yeah, how do the archive nodes look like for F2 and are block explorers ready for this? If you're a block explorer you would pretty much have to download every block on every shard which is one to 10 megabytes per second multiply by 86,400 we're talking 8,200 gigabytes a day so it's like you have more hardware requirements and then of course that's one issue the higher required requirements going up and another issue is that you'll have to deal like with ETH2 basically more things are being kind of layer twoified than before so you have execution environments and then within execution environments we're also planning to push forward on transaction abstraction and so now you don't have EOAs and contracts as different costs of things anymore and then you have cross-chart transactions and different ways of implementing them and so your responsibility to understand popular layer two protocols will realistically end up increasing and that's another thing that you might need to watch that you'll probably need to watch out for so I guess in general for being a general purpose block explorer is realistically one of the things that will get harder. All right we have time for one last question make it quick. So as an adapt developer that has an ERC-20 asset is there anything specifically we should do or maybe not do as we look towards YouTube one out? Right now no, in the future when I think I'm inclined to just say like don't think about the problem now and like in the future as the execution environments and if start becoming more nailed down then you'll be able to think more about like how to design the kind of token and like application specific details around a cross-chart context. But no migration specifically. Like there is a possibility you'll have to do a one-time token upgrade but that could also be done with a wrapper. Knowing that tokens are the most used function in the current chain is it not worth considering hard coding them and like making them much more efficient than they are right now? Or taking a snapshot potentially. What hard coding make them more efficient? Well because right now they execute code just to do basic functionality of the token. The code is like fairly as small right? Execution of EVM code is not like a dominant factor of like watching over head time. The one, okay so the thing that I would look into like if we want to like really optimize tokens heavily things that I would look into. I mean one is to just like review like the whole ERC-20 transfer from architecture and like think hard about do we want to build into like higher level of language standards a more explicit like pay for token with function calling strategy. Another thing to look into is that actually one kind of functionality that I think we'll likely put in is the ability to store pieces of contract code on the beacon chain and then have the ability to just reference them by address and this would like this would prevent things like account abstraction like tokens not being abstracted or tokens already being abstracted and all these other things from blowing up witness sizes because you'll instead of having a piece of code in your witness you'll just be able to point to an index. So a lot of those gains have kind of been factored into the existing design already. Another thing to look into that would it be kind of redesigning user accounts so that you would have the benefit of kind of being able to like you would be able to get the efficiency benefits of being able to hold like many units of a token within one particular package that could get passed around between shards but like there's trade off stare because from a privacy point of view if you want to improve your privacy it actually makes sense to kind of separate out all of your token holdings from each other and even have multiple accounts per token. So it's like in general I feel like there is a way like the optimizations are needed but there's generally ways to make the optimization without enshrining too many things. Well it's important to note the notion of owning ether actually becomes a layer two concept in EEs. So the only thing that owns EEs is the E has a balance and then there's some sort of presumably some sort of account model and state model within that EE that's defined that allows you to actually have a right to a portion of that ether. And so we've actually instead of enshrining tokens we're now like deshrining ether within the. All right we have to stop here. Sorry everyone. Do you want to talk? Less hard coded things at the end of the day is better. You know so like not having like a ERC hard coded just gonna be better because less hard forks less nonsense to deal with from a PM perspective.


Hello and welcome to another edition of JPL in 30, the highlights show for the Jamaica Premier League. With the playoffs in touching distance, teams continue to jostle for positions as the top six look to solidify their placing while the bottom half of the table look to separate themselves from the dreaded drop. This week, our highlights kick off with our usual Sunday doubleheader who saw a playoff outfit Tivoli Gardens locking horns with playoff hopefuls Dumby Holden at sea. Let's check out the highlights. No surprise that it will be a 3-4-3 and as you said, Anthony Nelson finally off the mark in the last game and Nikolai Fuller as well, so a big deal for them. Dumby Holden, they're starting line-up Damien Highton-Golz, Siddiqui Burton, Zaki Wilkes, Devonte Hodges, Shaquene Powell, Donovan Segri, Ricardo Thomas, Carleton Blackwood, Dwight Merrick, Pion Kupi, the schoolboy from Clendon College, Marlon Allen, Lennworth Hight, their coach. They'll be playing with a 4-3-3, Kupi comes in for the injured Fabio Makati. Full match highlights, Stephon Dwarves sent it off early in this one. Innocuous back pass from Zaki Wilkes on the normal circumstances, but there was no normal circumstance here, Damien Highton with a swing and a miss. And he must rue that when the highlight reel is played. Tivoli Gardens getting the go-ahead goal courtesy of Zaki Wilkes. Perhaps not necessarily against the run-up play. They had the right to start the Tivoli Gardens as evidenced by attempts like this. This one from Anthony Nelson to the side netting. And again, Nathan Thomas with a brilliant pass to Horatio Morgan. Trying to get it to Nelson, his first touch didn't set him up well enough. And a good defensive work as well also brought some help for Dumby Holden. Here's where the game would have turned for them. A shove in the back by Nikolai Fuller on Seriki Burton. Didn't need to do that to the youngster. And Riccardo Thomas, look where the ball ended. Firm in the back post and the supporters for Dumby Holden rejoicing. Here's where Tivoli Gardens almost went ahead. Shaquille Jones with a header that Damien Hight had to pull out all the stops. Stops literally. And Shaquille shot there. Damien Hight forced to make a save with his leg there. Again, tentacle. You'd have expected him to at least bring that one on target. Unable to do so. And this shot from Seriki and Paul flushed wide. Nicholas Clark was happy to see it go out of touch. And that's where the game ended. Full time. One all between Tivoli Gardens and Dumby Holden. Here's a full time highlight. Statistics rather. Two on target from nine attempts from Tivoli. One from four from Dumby Holden. 37 fouls. Only three yellow cards to Tivoli. One for Dumby Holden. No red cards. One offside for Tivoli. 11 corners. Six for Tivoli. Two saves made by Dumby Holden. And Damien Hight in particular. That overall lacked quality. And perhaps a fear result in the end. One all between Tivoli Gardens and Dumby Holden. The man of the match is standing with Chris Taylor. Let's hear what he has to say. Riccardo, another man of the match performance for you. Not an easy battle against Tivoli Gardens. But how important is it even to come away with a point? I think we did only three points. But we are grateful for the point. On the road, we are very grateful for the point. Riccardo, converting from the spot. Lenny, your captain put it away, but you must, when you analyse this one for us, I'm sure you would say it lacked quality. Yeah, man, definitely. A very ugly game today. I think the pitch. You see how the first goal scorer and us, it won some little moisture on the turf today. We didn't handle it well. You see why we play so much long ball today. I told them to just forget about the passing game and try and go direct. And I think both teams are doing that. That's why it looked like that. Not the easiest battle against this man, Jerome Wade. Well, Jerome, two tough battles and you haven't been able to really break down the double hold inside. Two draws in the season. Assess it for me. Yes, first and foremost, you can see the playing surface rub the team of some good football and that resulted into the game. You notice the first goal come from, you know, in the bumpy, this had a field result in the ball beating Hyatt. And then, you know, the other one is one of those things where the youngster can't make a contact result in a penalty. But the game is not much that you can talk about because the field wasn't good enough. But in the end, I think both teams, you know, gave a good approach to themselves. So Tivoli Garnes and Don Beholden share the spoils to sit in third and sixth place respectively in the standings. We take our first break here on JPL in 30. Join us for more after the break. Welcome back to JPL in 30. The second match in our Sunday double header featured former champions Harbaughu taking on the resurgent Molleins United. Let's pick up the full match highlights. Here's the Harbaughu lineup. Chains in gold, Romario Palma comes in for Glen Roy Samuel. Orderland Harding remain Breckenbridge, Garth Stewart and Akima Jones. The back four that has started for predominant part of this season. Tidalo Chikwimeka, DeMar Rose and Fred Bennett in the middle of the park. Ruan Brown, Amar Thompson and David Reed, the youngster at the top. They're coached by Ludlow Bernard, 4-3-3. That's how they line up. Getting ready for the Molleins United lineup. They line up as a 4-4-2 Peter Harstam goal. Enrique Gordon, Dane Samuels, Sean Doir and Romario McPherson. The back four, Jeremy Nelson, Johnny Fleming, Ronaldo Barrett and Javon Brown. The midfielders and Dante Duncan. A relatively new signing for them in his first start. Dante Duncan and Jason Wright up top. Of course, the leading scorer is Jason Wright. Full match highlights. Harbaughu coming forward. We're giving that one away rather. And Ronaldo Barrett was alert to the opportunity. Couldn't bring it on target. Dante Duncan in the first half and the best opportunity for Molleins. Forcing a double save from Romario Palma. Another look at it. Palma there in the thick of things. Did have an injured skier there. Harbaughu on the other end. We're trying to create some opportunities for themselves. This header from Omar Thompson. Forcing a save from Peter Harrison. Doing well at his near post. 30 seconds later, going low and eking that one out from the goal and Molleins kept in courtesy of his own brilliance. Brown Brown there. Causing bewilderment from the coaching staff. That was the end of the first half. Second of action now. Molleins trying to get in the thick of things. Jason Wright there. Far and straight to Garth Stewart. Again, turning. Getting the opportunity. Unable to connect with the ball though. Jason Wright leading the goalscorer for this team. But, German Elson came forward. Daniel Hardy the substitute collected. And what a delivery to the back of the net. Beating Palma at the near post with fury. Daniel Hardy what a strike. One nil for Molleins. The sport makes that moment. Sue, loving the action. Harbaughu they continue to try to fight. And at the end, Tyrese Williams another substitute for Harbaughu. Forcing a save out of Peter Harrison. And at the depth. Unable to keep their hopes alive. And that was the final whistle. Councillor Anderson falling things off in this fixture in the Reynaf and Jamaica Premier League. Full time stacks. Five shots on target from 11 attempts. Three from six for Molleins. Nineteen fouls producing five yellow cards. Four to Harbaughu on a one to Molleins. There were three offsites. Two of them to Harbaughu. They had six corners only one for Molleins. Two saves made by Palma in goal. Five made by Peter Harrison. And that pretty much kept them in the game. Harbaughu having the line of possession. 59% for Molleins with the all important goal. The one love. And what love is being shown to the goalkeeper, Peter Harrison. He stands by ready for the man of the match interview. Peter, clean sheets have been hard to come by for my lines. How big was this one today? This one was a very important one, you know. Every match you play from now is a final. I want to stay in the league and keep playing top football in Jamaica. You're very vocal, especially in the first half with that double save. Just talk to me what goes through your mind with a lot of action happening down by your end A.K.A. in the second half and then turn up with that big save just near the end. Here I have to keep focusing on right through the game because in the previous game we were dropping points at 99 to 1 minutes. It was a very crucial save at the end. A 1-0 win for Molleins and in fact the first time that Molleins have ever defeated Harbaughu in the Jamaica Premier League. The frustrations continue for you, Ludlow. Not the result you are looking for obviously. Not the result but of course I think I can speak to the effort that was made by the guys out there, you know. Some good goal keeping certainly denied us of some good chances that we got but there is one clearly at the end of the first half which you should have taken and that would have changed the whole process at the game. Head coach of Harbaughu and a struggle. Jermaine, well, history has been made today. I'm not sure if you knew of this from before but it's the first time Molleins have ever defeated Harbaughu in the Premier League. It took some time but well deserved victory for you today. Yeah, I mean I heard about it. We came into the game knowing that I told the team we wanted to to accumulate at least 30 points at the end of the season and we are working towards that. Strong team even the changes off the bench had a big impact. Daniel Hardy missed out on a starting position today but yet came off with the kind of energy needed to it to score the kind of goal he scored. I mean good we started well in the probably first ten minutes of the second half we kind of we introduced Arden and Dennis and Livingston and they impacted immediately and I thought that really made a difference. So Molleins United continue to pull away from the bottom two as their fifth win see them move into ninth place in the standings. Daniel Hardy review continued to struggle after suffering their eleventh loss and are just above the relegation pack. We take another break here on JPL in 30 more football action right after this. Welcome back to JPL in 30. The lone Monday night fixture saw home side Arne Gardens taking on bottom club Lime Hall Academy. Here are the highlights. Let's see if the encounter will be in a favor of the visitors or the home team. Let's have a look at the starting line up Ronald Garnes, Erik Edwards in goal Joel Cunningham, Shivani Willis John Drake Cunningham Belanda Wing, Rashane Thompson Jamone Shepherd, Roderick Grangville Martin Martin, Rashiki Kelsen and Kahim Dixon. Their head coach is Xavier Gilbert. For his rise for Lime Hall let's have a quick look at their lineup. Damien Robinson in goal Damani Sewell the captain Ron Sewell Carlos Campbell Jamoy Jones, Devonte Redman Marlon Penicill, Sejay Anderson Marlon Buckley, Gavin Harrison and Omar Walters their head coach is Hopten Gilchrist. Full-time highlights this matchup had the predators versus the prey in the jungle and Arne Gardens they started well. Cunningham there at the near post trying to cause some damage there was some amount of self-inflicted wounds from Lime Hall almost causing danger and Rashiki Kelsen his shot going wide and Jaheem Williams making that error but had a good save in this particular instant blocking Jamone Shepherd from his shot through on goal and again he came up trumps after Kahim Dixon fired with fury what a save from Williams his second real save of the afternoon and there were some more moments for him here perhaps a comical moment Marlon Penicill free on goal and there was nothing to right home about from that one first goal came from that delivery from Philando Wing ended up being an own goal Buckley under pressure from Kimani Arboy in the substitute he headed it in his own goal this appointment for Lime Hall they were standing firm but architects of their own demise in that particular instant only a minute later Jaheem Thomas playing that one forward ball played in the path of Kaheem Dixon and a goal hungry Kaheem Dixon will do nothing but convert that Jemoi Jones giving that one easily on a platter to him and Jaheem Williams more frustration but more joy perhaps the flick will have to be worked on but he had the goal Arboyn saved Shea Smith lined up that one had a wicked deflection that he went off the upright as well danger averted in the end here comes McGregor across there was an offside call there and Arboyn combining with Dixon again another save and McGregor off the upright Shea's Jaheem Williams injuring himself in the landing and eventually would have to be substituted another strike here from Thomas good build-up play from Deontre Cunningham and Thomas the substitute finishing Cooley that was goal number 3 400 gardens Jaheem Thomas getting that one another shot in the end after an outfield player came in the goal and kept them in a respectable margin Nikolai McCoy what a moment he had in the final moments in goal for Limehal here's a full-time statistics 14 shots on target from 23 attempts still Limehal having no shot on target 3 attempts some 21,000 this encounter 2 yellow cards to Limehal players 1 200 gardens 1 offside 400 gardens 8 corners 5 400 11 saves made by the combination of Jaheem Williams and Nikolai McCoy and 35% of the possession to Limehal 65 200 gardens and 3 goals as they consolidate themselves on equal points with the rest of the table but they are behind goal difference they are jointly on 42 now with Tivoli and Portmore 4th and 3rd respectively they are still in 5th we are standing by for the man of the match interview let's hear what Philander Wing has to say Philander from your high school days you have been a real utility player for all your coaches how much are you enjoying the overlapping left back role for Xavier Gilbert well it's good but I'm still growing at the end of the day so it's a learning process for me and look for more this season how much more does it require from you to actually go up in the attacking third and then get back and execute those tackles as well well I'm a player that run, like to run so it's not an hard task for me Oceane a tough one as you expected again today you have on your bag already ready to go home but for some of the games, spirit and performance but you fell away in the second half yes it was a hard part but I guess after the own goal it brings the team in a sleeping mood and we don't know what comes after extra small squad for you today as well that must have been disappointing what only four substitutes the end of the game actually with ten players because you didn't have an additional substitute how tough was that for you well not the additional substitute but we run out and it's because of the windows but I see we shot and gears today because we got the away gears shot and some players have their gears at home so even though you conceded three goals Jaheem Williams was brilliant between the sticks he must have been one of must have been has been one of your standout players so far this season well I have him for the matter of the match for tonight but I guess the three goals be to them today Javier, not the most fluent performance by your team but at the end of it it's the first three points against Lime Hall yeah and that's what counts in the three points we really wanted to put on a better show I think we're a little bit impatient especially in the first half we were in connecting and passes second half was a little bit better and we managed to put them under a little bit pressure and score some goals but it wasn't our best in terms of fluidity but such is the nature of the game so we're glad we get it you spoke to the team about the need not to be complacent in that first fixture you thought complacency was one of the reasons you started the second half was a bit slow did you at any point feel that it was complacency from your team for the second half to be honest second half we made some adjustment players bring different things when you're looking at the game and think what this player can bring to this game now in terms of their position their creativity and what they have to offer and I thought that we just needed a little bit more life a little bit more spark, a little bit more positive going forward we got that from the person who came on here's the table after the full list of matches in matric 22 Mount Pleasant 49 points Cavalier just behind them on 45 points Tivoli Gardens Port Mernonnet jointly on 42 points with a gold difference seeing Tivoli Gardens stay ahead of Port Mernonnet don't be holding round on the top 6 with 34 points so Arnett and Tivoli and Port Mernonnet perhaps safe in the top 6 at the moment as Waterhouse and Montego Bay in 31 on 31 points 7 and 8 but at the bottom Treasure Beach and Lime Hall 12 and 7 points effectively Harbourview and Humbline just outside the relegation zone 19 and 22 points and that's how we put a wrap on another edition of JPL in 30 on your home of champions on SportsMats tune in next week for more exciting football action


And the United Nations has launched a global appeal fund for the volcano-stricken sister aisle. Prime Minister Hon. Berth Gonsalves taught the Red Zone with a UN team, as Khalil Kato of SVG-TV. Prime Minister Gonsalves said that the communities have long faced multiple threats from nature, including sea erosion, hurricanes, unseasonal and excessive rainfall, and most recently the eruption of the volcano in a time when the entire nation is battling the COVID 19 pandemic. Berth Gonsalves said there is quite a bit of work that will need to be done in the area as homes which were not totally destroyed will need extensive repairs. The Prime Minister said he wanted the United Nations officials to see first hand the level of devastation unfolding on the island as a result of the eruption of the La Sufra volcano. The combination of forces of nature piled up from the last event with rainfall, excessive rainfall and landslides and mudslides and the rest. The impact of the rumbling and rolling of stones too and the ash fall and on top of that what we are seeing with sea erosion so it's the multiple problems in this case three of them related to nature. Several persons in the delegation from the UN used in the world to describe here apocalyptic. UN resident coordinator for Barbados and the Eastern Caribbean, Didier Trebuk described what he saw as apocalyptic, noting that his team will be working alongside the government of SVG to provide assistance to those in need. The United Nations to help the people of St Vincent and Agronadine to with not only humanitarian assistance supply to have the government supplying the most basic needs like water, like food, like cash voucher, like air and help with the cleanup of the ashes and all related environmental issues but also to recover from this crisis, to rehabilitate the country, to look at the housing and shelter in need but also more local needs so that people can return safely as soon as possible and within the current risk that exists. Trebuk further stated that all facets of the United Nations have been mobilized and a donation of two million US dollars in aid will be given to SVG.


I really love the topic of the conference and I wasn't sure what I'd talk about, so I of course wrote down the most generic title I could think of that somehow talked to the conference. What I'm really going to talk about is a few of my favorite things. So my most favorite thing is quantum error correction. That's what I think about most of the time. It's not on this list. I'm going to talk about my other favorite things, which are Ising two cubic gates, composite pulses, and the Bernstein-Vasarani algorithm. I wanted to make a list of not my favorite things so I could talk about how much I don't like Grover. I'm not a big fan of diamond distance, but I decided not to do it. What's our real problem? So the way I think about it, our real problem is that we have a few number of qubits and we don't have very good gates. And so it's always, just last week, this number here was 45 or so. Like the number of qubits that we can classically simulate continues to grow. We know that to do algorithms we not only need to have enough qubits, we need to have enough effective gates. So like quantum volume is one way you can measure that. And then if we actually think about specific algorithms, there are of course classical tricks we can apply. And that leads to kind of a swoop up like this, excluding more and more space from where we can show some sort of quantum supremacy or quantum advantage. So I work a lot with IonTrap. So just a brief idea of kind of where IonTrap quantum computers are at the moment. So what's nice is at the limit, you know, there are these beautiful penning trap experiments from NIST which have hundreds of Ion qubits, but limited control. There's this recent paper from Maryland where they have 53 Ion qubits and they do a transversizing model simulation. At full control there are about 10 or so qubits, both at Maryland and in Innsbruck. There are, for two qubit systems, really good gates both at NIST and at Oxford. And actually the Oxford guys is really quite amazing. So in 2015 they had a gate which was 99.9% good at 100 microseconds. And now they have a gate which is 99.9% good at 2 microseconds. So there's no more qubits, there's actually no more improvement in the gate fidelity, but there's a tenfold improvement in speed, a hundredfold improvement in speed. So the thing is we'd like, of course, to somehow reach this region. So first we want to get to some place where we can do some of these variational or approximation algorithms which we imagine somewhere around here. We'd like to maybe get out to factoring and like really like the harder, like the phase estimation kind of quantum chemistry problems which are somewhere out here. Because I'm interested in error correction right now, my error correction goal is basically here which is looking pretty good, I just have to pull these lines together. But I want to talk about gates. So here number of qubits is clear, effective number of gates is obviously a fudge, I mean effective isn't the title. And so, you know, the simplest way to think about effective number of gates is you can say, well, if every gate has the same error, one over the error tells me roughly how many gates I can do, right? So what error is a good question, think about fidelity loss, think about diamond distance? Do all the errors matter? And actually I thought Eddie had a good point which is, you know, if I'm running this optimization thing, if my state's a little bit off, I can still get a measure of the value I want even though the state's not correct to say it. So I think a great, a paper which really inspired me was this paper about can you actually trust quantum simulators? So in this paper what they looked at is they looked at a transfer sizing model and they said imagine you're doing an experiment on a transfer sizing model and you have some error, some fractional error basically randomly shifting your parameters. Now because in a transfer sizing model you have this really nice phase boundary condition from a say a paramagnetic phase to a ferromagnetic phase, if you're an experimentalist you take a point here, a point here, a point here, and a point here, and on this whole plot you claim success because you see paramagnetism on the left and ferromagnetism on the right. If you wanted to do something more quantitative you could actually try very carefully to measure where this critical point is. And what you see is even with these rather large errors, even with these rather large errors that the, you know, you measure the critical point about the same point. And I think that has to do with in some sense the robustness of phase transitions which are a sort of error correction itself. So what I, motivated by this conference I was like well what if I wanted an answer, an exact answer where there's no, no room to fudge anything. It's a bit string which has to be one bit string. So I immediately thought of my favorite thing, Bernstein-Vasarani. And so Bernstein-Vasarani, there's some oracle which outputs, right, this dot product of x and s and our goal is to find s. So classically, right, we can just ask, we can put a one in at every input bit and zero is the rest of the place and that will feed us out s after n queries. Quantum mechanically, we can do it in one step. And there's no, right, there's no, like, there's only one s. There's not a fractional s, we, we need this one step. Now of course the problem with oracle problems is nobody's going to give you this oracle. So we should have some way to implement it. And one easy way to implement this oracle is to have control knots between here the data register and then this target register. And then the computer randomly picks s, randomly programs your quantum computer to apply these things. So, you know, Bernstein-Vasarani is great. We just put a bunch of hadamards around it. We use our good friend phase kickback. And when we measure out here on these, we measure here in the z basis, we just get out s in one shot. And so the question I wanted to ask was, well, yeah, how does this, how does this interact with noise? How does this interact with near term noise? How do we get this s? Are there tricks we can apply to make things better? So again, just for concreteness, I'd say, assuming that all of the gates are bad, but mostly, in most, I think in most experiments nowadays, two qubit gates are worse. In ions in particular, two qubit gates are much worse than single qubit gates and measurements. Two orders of magnitude worse. So they're good. They're like 10 to the minus 2 or 10 to the minus 3. But the single qubit gates and the measurements are much better. So to have the worst case scenario, we want to pick the s, which of course triggers all of these control knots. Now people have been doing experiments on this already. So for example, this five qubit implementation, which was a paper by the Maryland group with Microsoft actually using the IBM quantum experience. One thing which is nice about the Bernstein-Vasarani algorithm as drawn here is that it's very good for a fully connected implementation, but also like a wheel connected object. If I had a two dimensional grid, then the cost of doing these distance control knots become kind of an interesting thing. Actually, since we're on this plot, I also wanted to point out that what I like about this is if you can't do Bernstein-Vasarani, I mean, what can you do? And I think these Clifford Gate circuits are actually a great way to test things because we know what the answer should be. We don't have to worry about some distance between estimates of random output distributions. And then also I think it's a really great way to test kind of the reliability. So ideally you would think, okay, every control knot has the same error, but in fact in your system they may not. And you can actually see that by testing over distributions of different S's. So in this paper they compared this iron trap setup and the superconducting setup. And what you see is depending on the, this is the S that is encoded into the Oracle. This is the S which is estimated. You see they're both good. They both have these nice linear progressions. You can see that the iron trap has slightly better fidelity. What's interesting to me though is if you look at the deviations in these plots, from how the fidelity would look if all of these things were actually independent, you can actually learn a little bit more about your errors. And so I spent most of my time thinking about this. So here there's an error in the classical detector, which the classical detector goes high. There's some probability that its neighbors will also go high from a classical crosstalk. And you can actually see that if you very carefully look at these dips. All right. Now the other thing I really like about these Clifford circuits, and we use it all the time when we think about quantum error correction, is the idea of fault paths. So in a Clifford circuit, if I have poly errors, I can just walk that poly error through the whole circuit. So we did this, so this is built for quantum error correction. We made a slightly different implementation of the fault path. We call the fault path tracer. We actually were working currently on a tensor network implementation of the fault path tracer, which allows us to look at some larger problems. But the basic, but what we did in this paper is we applied it to Bernstein-Vasarani. And then we can actually calculate if you have poly error noise on your gates. Exactly what the probability output should be. Not only just the s, but all the probabilities. And then you can actually use that as kind of a witness of whether or not your quantum computer has these sort of depolarizing noise or it has some other kind of coherent noise that shows up. But the main point is, since I'm measuring here in the Z basis, what would make this go wrong? What would make this go wrong is if there was an X error right before the measurement, which is equivalent to the measurement given either on value. Or if there was a Z error before this Hadamard, which then transforms into an X. Or there's a Z error that came from this controlled knot. Or there's a Z error that happens below the control knot and propagates up, right? So I can just walk back all of the places that the error, that this, right, which should be my value of s, this bit of s, where will it go wrong? Where could it go wrong? All right, so here's just some examples, right? So if there's an X error here, it flips that bit. If there's a Z error out here, it flips the bit. And if there's a Z type error, which could be, say, Y, down on this bottom line of these controlled knots, it, of course, is sort of the most damaging error. And it will flip up multiple bits of our solution. Now, I'm gonna move to the model where the only thing that has errors is controlled knots. Because I think that's basically, again, I think for ion traps it's a very reasonable model. And so this is also my list of least favorite things, is the two qubit depolarizing channel. I don't understand where this comes from. I don't, so let me, I do, that sounds too bad. But no, I mean I understand that I'm taking unbiased sample over all of this two qubit poly space. But I can't write down a physical model, which gives me that naturally. I've never seen any, all of the physical models I've looked at has never come up naturally. Now the single qubit depolarizing model I think is really quite good. Because that's basically the limit where I've lost track of my angles of both the phase and the theta. I think that makes perfect sense. But the two qubit depolarizing model doesn't make any sense to me. But it's the most common thing used theoretically. So what we notice is that xi and xx actually do not affect the algorithm. So there's two out of these 15 things that could go wrong, which reduce the fidelity of the gate, but do not reduce the algorithm, the algorithm output. There are these four, which just flip that one bit of s. And then there are these four, which because they trigger those cascading c-nauts can flip multiple bits of s. Okay, so now a good question of course is, well, I don't believe in this two qubit depolarizing noise, like what do I believe? So I believe actually, yeah. I think in most systems, the two qubit error that occurs strongest right now, right, it will eventually make it lower, so it will be something else, is aligned along the axis of the gate. So I think the key two qubit error for a controlled knot gate is in fact this zx kind of error, which flips one bit. So in some sense, if there's a probability of this happening, it's a little bit worse because this two qubit depolarizing channel has a couple of errors that don't matter. On the other hand, you don't get any of these really disastrous errors for multiple bit flips. Okay, so now of course, why do I think this is true? And this is where we're going to start to talk about easing a couple gates. Actually, so the first quantum computing experiments I did was with NMR, with zz-type coupling gates. And now, we work a lot with Mollmer-Sorinstein-type gates and ion traps, and there it's an xx gate. But it's the same, everything's the same up to a rotation. So basically, this Mollmer-Sorinstein gate on these two qubits generates an easing-type rotation, which is perfectly good for this robust phase estimation, like this is the knob that's in the lab. You basically turn this theta, you see what you get. And we called the Mollmer-Sorinstein gate. There are these single qubit gates whose job is to basically transform this entangling gate into actually the CNOT unitary. Now, as the last talk said, like the key thing in the lab is sometimes you don't know, yeah, Shelby said, you don't know what the angle is. So I think of the error of this gate being a small, right? It's a small misrotation. And I'm going to imagine that the small misrotation either changes from gate to gate fast enough, or just randomly between gates that I actually can't use these characterization techniques to get rid of it. I've done everything I can to get rid of it, but there's still a small little epsilon. Now, because of these single qubit gates are perfect, all they do is they transform that poly operator to this zx operator, right? And that's why I think two qubit gate errors are aligned with the gate axis in some rotation space. So imagine this epsilon is totally random and it basically ends up becoming a stochastic poly model over zx. So we showed recently that it actually has some impacts on error correction. So this is a funny code we call the Bayer 713 code. Andrew Cross pointed out to us because he said that if you had single qubit errors on your gates in a circuit model, it would be fault tolerant to single qubit errors. And then my student, Meeon, led the charge to see, well, what happens if we add in two qubit errors? So what happens is if we add the depolarizing channel, because it's not a CSS code, yeah. Because it's not a CSS code, the X and Z channels aren't clean. And as a result, those things which can kind of propagate up flags later can cause a lot of damage. But if you give us our stated thing that we can have this anisotropic error, then it's fine. And so when we looked at the performance as a function of the physical error rate, if we allowed for the anisotropic error, you could actually see what I think of is real sort of pseudo-threshold behavior where the error is quadratically suppressed below some rate. But if we use a regular depolarizing error model, it's actually kind of interesting to me it gets better than the physical error rate, but just like by a constant amount, right? And so I would say this isn't quite fault tolerant. So there's an example already of if we, particularly in the near term, if we know something about the angle, the axis of the error, we can do something better. Actually, Steve Flamilla has a nice result on generally in codes. If you have like a very anisotropic single qubit error, you can basically, some sense, change the gauge of your stabilizers to improve your ability to find incorrect errors. All right, so now to the next of my favorite things, which is composite pulses. So I actually think in the lab what happens is that this tiny over-rotation is a systematic error, which is slowly drifting in time, as Robin was mentioning. And so as long as we act in a small time slot, even though we don't know what that epsilon is, we know it's basically the same. So this is already been used for single qubit gates in Bernstein-Vaserani. So this is some work that I did with the folks at GTRI. This is just three qubit Bernstein-Vaserani. But you'll notice here that there's a single qubit gates here. But down on this diagram, you notice that actually both of these lines have somehow this purple bar on it. And the reason is, is the way this experiment was set up is the laser was wide enough that it could always see two ions. And so if you tried to center it on just one, you'd always have some spillage to the next. But you knew what that was. And so there's a type of composite pulse called passband one, which allows you to both correct for small changes in the over-rotations and also to cancel the residual error on the qubit, which you shouldn't be talking to. So if you have these systematic errors, you can use quantum control to get rid of them. So composite pulse sequences. Here are just two examples. The idea of these examples is I want to rotate from the top of the block sphere to the plane. And then what I do is I apply a series of extra rotations, which should do nothing. And they allow me to correct this gross error here. So I come down one, over two, this way to three, and back to four to basically correct that piece. So this BB1 is a very good sequence designed by Winpris in 94. In 2004, Aram and I showed how you could expand it to arbitrary order. And then in 2014, Lo and Yoder were able to show how to do it efficiently. So now let's think a little bit more about this. So it's unfortunate anyway. I wish I would have written this review after the Lo and Yoder paper. That's my only concern. So this, so if you, it's easier to think about the error in terms of the sort of Lie algebra. And so if I over rotate, I can think of that as a error, which is along that axis of the rotation. And it will have a distance epsilon theta, this fractional distance. What SK1 does is SK1 applies two rotations by two pi, such that you get closer to here. And the residual error is actually the area of that triangle. And then as we know, it has to do anyway, it has to end up doing with the cross product. And that area has a direction. And the key thing is that it's out of the plane. So instead of being along the axis we saw before, I can now make this error somehow out of the plane. Now BB1, the reason why it's so great is that it basically does two of these triangles, cancels out that area. And then there's some kind of leftover volume, which points somewhere, somewhere on the plane. So Jones showed in 2003 that you could basically take all of these single qubit composite pulses. And if you work on the assumption that the single qubit gates have no errors relative to these qubit gates, you can actually just apply them directly. But what you need to do is you need to find three new representations of, say, SU2 angular momentum, three different generators. And then actually, my students and I showed that we couldn't actually find anything else to do. And then low and yonder, this whole idea of cubitization of simulation, all these things kind of come from this idea that basically the knob of non-commutivity is always like a qubit. So now I can make this SK1 style two qubit gate. But I have a choice, because I can actually control whether this axis is a y-x axis or a z-x axis, which then makes the error, which is pointing out of the plane, point in different ways. Also notice that I've taken basically a two qubit error and used it to turn it into a one qubit error. I also want to point out that I could make a big mistake and push that two qubit error into a one qubit error onto the qubit, which then triggers all of those other errors. So this is a catastrophic choice. We'll see this one is a good choice, and this one's an OK choice. So let's look at those two top two choices. So I could either, now that I've had this composite pulse sequence, I can either have a yi error up here or a zi type error. And then when I push them through my single qubit gates to see what comes out the other side, what I see is that the leading error here is just invisible to the measurement, like the measurement doesn't see it. Here, this leads to an error on the measurement. And so I thought a good way to look at it is if I look at kind of an entanglement fidelity, gate fidelity, what I see is that the fidelity, so this is my, the fidelity of my, this is the over rotation epsilon. So first notice this is pretty gross. This is like a 50% mistake in your angle theta. The beautiful thing about these sequences is they help out to very large over rotations, and over rotations that you expect, you really get a substantial win. Both of these two, so they could tie up two qubit gates, will have, of course, the exactly the same gate fidelity, because at the limit of the algebra, they just look the same. But when I think about the measurement, what happens is that the one that generates the Zi, the fidelity basically directly connects to the error of the measurement. The measurement fidelity, so measurement fidelity in this case is the probability that I don't get the right bit of S. Or sorry, the probability that I do get the right bit of S. And we see that for Mohler Sorensen and this SK1 where you haven't taken care to have the vector go the right direction, it just matches the fidelity. But if we take time to actually rotate that leading order to be in a way that doesn't cause error, we see that it actually improves the fidelity. These guys were together before. And it actually has kind of a neat property that down here, you actually have a gate which has lower gate fidelity relative to the blue line, right? But improved overall algorithm fidelity, which is kind of nice. So there's some, yeah, to summarize that again, these gates have the same fidelity, but by controlling the direction of the error and using the fact we know what error is invisible at the end, we can make the overall measurement error and the overall algorithm error go down. Okay, so now, of course, you should look at higher orders. And I would say in some sense, I really like BB1, but it's too good. So when you look at BB1, it outperforms, of course, all these SK1 sequences. It takes the same amount of time, so you should just do BB1. What is nice is that PB1, which is also a higher order sequence, but takes twice the amount of time. Surprisingly, it turns out that its measurement error exactly lines up with the SK1 error, where I take the time to put the error axis along the right direction. All right, so now, these are not, this sum here doesn't mean that the sum is balanced. It just means those are the two key Li algebra elements. So it seemed like, okay, well, I can probably, I know that this term here, I could shift to be a yx term. And so I tried that. I tried different types of BB1. But although on this plot, it looks like a big gap, it's just negligible. Once you get to that order of error, it doesn't really seem to make any difference. All right. Okay, so now the question is, well, what can you do with more algorithms? And the answer is we don't really know. So I have an undergrad, Daniel Murphy, who's been working with me, where we've shown that if you do an inverse Fourier transform, if you do a Fourier transform measurement in a Cataya style model, we can use all of these same tricks to make it work. If you do it in the more, if you do it in the shore style phase estimation algorithm, basically all of those controlled rotations, which may or may not happen, don't allow you, you don't know what axis you're trying to hit, right? So you can use that for or against you. Now, I think what's nice is of course you can't, you're not going to solve everything with this, but you can actually trace, because if you think of, if I think about the axis of error for just a single gate, I can of course trace that out through the algorithm without, well, depending on the algorithm, without too much cost. So in conclusion, yeah, so to keep it to polarizing channel is not well motivated. If you have a motivation, let me know. I think quantum control, it's interesting because we could either use it to minimize gate errors or algorithm errors, and we should be conscious of that. I think the most important thing is that, and I think maybe it, it's not just the error that matters, right? It really is that axis of error. And so if you don't know anything about the axis, then fidelity is fine. But if you know something about that axis, there's probably some trick you can use. The next thing I wanted to point out is that quantum, that these, it's sort of funny, so when I'm thinking about quantum error correction, I'm always worried, worried, worried, worried about coherent errors. But when I think about near term quantum computers, I think having these systematic coherent errors actually gives us more knobs to play with, because if it's still that systematic noise, I can both minimize it, direct it, do all these things. And then finally, I really do think that although it's going to be great when we can show this clear gap, if I want to show that my computer is working, I should run things I know the answer to, like I should run Bernstein-Vasarani. I should even do reversible classical computing, right? So if I can't do reversible classical computing, I also can't do quantum computing. So, with that, I just, yeah, so this is the group, I make for all kinds of funding from the NSF, the Army, IARPA, and the Humble Foundation. I'm moving to Duke more or less tomorrow. I could really use a quantum error correction postdoc, but anyone in quantum information theory please tell them to send me an application. Thanks for your time. Okay, thanks very much, Ken. Questions? I was trying to really argue this for you with something you said, and I'm still having trouble. So, great talk. What do you have against diamond norm? Oh, so what I have against diamond norm is it's not a good predictor of algorithmic success. I don't even think it's a good predictor of error correction success. And I think the oftentimes gate fidelity ends up being a better predictor. I mean it for bear, I probably mean it for bear circuits as well, because I think it has to do with, so in Bernstein and Vazzarani, the circuit's so simple that you don't have enough time for these coherent parts to get their coherent damage. And then if I think about randomized circuits, then I think that the diamond distance gets scrambled, and so it doesn't really do its damage. And then I think the only interesting counter example was Michael's work with the, where I have only these Z gates in the middle, right? There, these coherent errors, like the diamond distance during that intermediate part probably is the right norm, because it should add up like that. Okay, any other questions? Okay, so if not, I guess let's thank Ken again.


Welcome back everybody. Jeff Frick here with theCUBE. We're at the RSA convention in downtown San Francisco. 40,000 people talking security, trying to keep you safe, keep your car safe, your nest safe, microwave safe, refrigerator safe. Everything safe. Oh my gosh. Jason Porter, VP Security Solutions from AT&T. Welcome. Very good. Thanks for having me, Jeff. So, what are your impressions of the show? This is a crazy event. Oh, it is crazy. I mean, look at all the people. It's the crowds. It's a lot of fun. You know, the best part is just walking the hallways, getting to connect with friends and network and really create new solutions to help our customers. It seems to be a recurring theme. Everybody sees everybody who's involved in this space is here today. Oh, absolutely. Yeah. For the next couple of days, it's just all in all the time. So AT&T, obviously big network. You guys are carrying all this crazy IP traffic that's got good stuff and bad stuff, a lot of fast moving parts, a ton more data flying through the system. It's kind of your kind of step back view of what's going on and how are you guys addressing new challenges with 5G and IoT and an ever increasing amount of data flow through the network. Absolutely. So you're right. At AT&T, we see a ton of traffic. We see 130 petabytes of traffic every day across our network. So our threat platform, we pull in five billion threat events every 10 minutes. So five billion events every 10 minutes. Every 10 minutes. That's what our big data platform is analyzing with our data scientists and our math. So lots of volume and activity going on. We have 200 million end points all feeding that threat platform as well. So what are we seeing? We're seeing threats continuing to grow. Obviously, everybody here at this show knows it, but give you some concrete examples. We've seen a 4,000% increase in IoT vulnerability scanning. So IoT is something, as a community, as a group here, we definitely need to go solve. And that's why we launched our IoT security alliance last week. We formed an alliance with some big names out there like Palo Alto Networks and IBM and Trostonic and others that really we all have a passion in going out and solving IoT security. That's the number one barrier to concern for adopting IoT. Okay, so you touched on all kinds of stuff there. So let's go to the big data. So what's interesting about big data, and I always tell my kids, right, every coin has two sides. Absolutely. The bad part is you've got that much more data to sort through. But the good news is you can use a lot of those same tools. Obviously, it's not a guy sitting with a page or waiting for a red light to go off. That's right. Analyzing that. So how has the big data tools helped you guys to be able to see the threats faster to react to them faster and really get more proactive? That's a great point. So cybersecurity is a zero percent unemployment field, right?  So we had to really evolve a few years ago. We had to make a big shift that we were not going to just put platforms and people watching screens looking for blinking red lights, right? So we made this shift to a big data threat platform that's basically doing the work of identifying the threats without the people. So we're able to analyze at machine speed instead of people speed, which allows us to, as I said, get through many more events much more quickly and allows us to eliminate false positives and keep our people working really at that looking at those new threats, those things that we want the people analyzing. Right. Okay. So then the next thing you talked about is IoT. Yep. And my favorite part of IoT is autonomous vehicles just because I live in Palo Alto, we see the Google cars all along, and they're coming soon, right? Absolutely. But now you're talking about moving in a 3,000-pound vehicle, potentially somebody takes control. So security is so important for IoT. The good news for you guys, 5G is going to be a big part of it, not necessarily just for security, but enablements. So you guys are right in the heart of IoT. Yeah, we are. You know, we have one of the largest IoT deployments in the world. We have the most connected devices. And so what we see is really a need for a layered approach to security. You mentioned 5G. 5G is certainly a part of getting capacity to that. But when you move to IoT with connected cars and things, you move beyond data harm to physical harm for people. And so we've got to be able to, you know, up our game. And so a layered approach, securing that device, putting malware detection, but even threat and monitoring what's going on between the hardware and the operating system and the user, and then segmenting, say, in a car, telematics from infotainment, right? You want to really segment the telematics so that the controls of driving and stopping that car are separate from the infotainment, the internet traffic, the video watching, Spotify, whatever, right, right, right. And so we do that through SMS, private SMS user groups, private APNs, VPNs, those kinds of things.  Make sure you do full UTM, you know, threat capabilities, throw everything you can at that. We've even got some specialized solutions that we built with some three-letter agencies to really monitor that control point. Right. Well, then the last thing you touched on is really partnership and co-opetition and sharing, which has to be done at a scale that it wasn't before to keep up with the bad guys, because apparently they're sharing all their stuff amongst each other all the time. Absolutely. And here we are, 40,000 people. It's an ecosystem. So how is that evolving in terms of kind of the way that you shared data that maybe you wouldn't have wanted to share before for the benefit of the whole? Yeah, so our threat platform, we built it with that in mind, was sharing. So it's surrounded by an API layer so that we can actually extract data for our customers. Our customers can give us their data. You know, it's interesting. I thought they would want to pull data. But our biggest customer said, no, you know what? We want your data scientists and your math looking at our environment too. So they wanted to push data. But speaking about alliances overall, it's got to be a community, as you said. And our IoT security alliance is a great example of that. We've got some big suppliers in there like Palo Alto. But we also have IBM, IBM and AT&T are two of the largest managed security companies in the planet. So you would think competition. But we came together in this situation because we feel like IoT is one of those things we've got to get right as a community. All right, Jason, I'll give you the last words. 2017, we're just getting started. What are kind of your priorities for this year? What will we be talking about a year from now at RSA 2018? Well, you're going to continue to hear more about attack types, different attack types, the expanding threat surface of IoT. But I think you're going to continue to hear more about our critical infrastructure being targeted. You saw with the Dine Attack, you're starting to take out major pieces that are impacting people's lives. And so think about power grids and moving into some more critical infrastructure. I think that's going to be more and more the flavor of the day as you continue to progress through the year. All right, well, hopefully you get a good night's sleep. But we want you working hard. We're all rooting for you. We're all working hard. All right. He's Jason Porter from AT&T. I'm Jeff Rick with theCUBE. You're watching theCUBE from RSA Conference in San Francisco. Thanks for watching.