Captain's Mark obviously alluding to the fact that Everton have had quite a few different captains already this season. Tom Davies seems to be in vogue at the moment as he's asked if it. Obviously we've had James Coleman, Jack Ylch y Day 1, Gilfy. Coleman, Jack Ylch y Day 1, Gilfy. As he's rightly said, so I mean he talks there in the video mark about the importance of a captain. Obviously you know mentioned Dave Watson, mentioned Kevin MacLeod back in the day. I mean what's your view on the role of a captain nowadays? Yeah I think obviously it's changed hasn't it? Back in the day I think the captain was doing that by example from a physical point of view. I think so, a lot of them the captains that you think back you're very keen, you're very serious and obviously for us you know you're Watson, you're very sensitive. Leave by example from a physicality point of view and that's gone from the game now you're not allowed to put those type of tackles in. So I think the role's definitely changed but it still doesn't for me doesn't mean that the person needs to be a natural leader as a person. And again I think that goes on and off the pitch. I think if the person leads just by example in terms of what the club means and everything that it means to be a captain needs to be transferred off the pitch as much as on it. And I think you need one person and not be changing it every week or every couple of weeks for me. I mean who would you, out of our current squad who would you? I think that's where we struggle isn't it? I think we struggle with that. I think personality wise I've had Pickford but he's rolled on the pitch probably doesn't. For me I just don't think a goalie should be a captain I don't know but from that character he's got the will to win and you know he's shot. Yeah and gives it large so I think for me he's probably the player from a characteristic point of view but other than that I think we're struggling. It's probably the position we struggle with. We need natural leader. Not Coleman. A lot of what he does I would say transfers to being a captain obviously from for the club and the fact that the fans are so behind and what not. But I think when he's had it and I don't know if it's just coincidence but when he's had the captain's arm and he doesn't seem to perform as well I don't know if the pressure of it gets a bit to him. I don't know whether he takes to it as well. It is a difficult one because I think probably the last kind of vocal captain we had was probably Phil Neville who would challenge the referee and ask for things. I don't think we do that well enough as a team. I think and I know we probably need someone who will do it because nowadays the refs are only saying to everyone at all to the captains anyway don't they? Because I just see other teams refereeing the game.  It was in the captains and the referees are here all the time and for years they've been here and refereed the derby didn't they? And there's all of that. Everton haven't really had that. I don't think. I mean Phil Neville was a vision of that but even he was too accept and I think something like that. The only one that we've had and I think he had there for a couple of games was Rooney. I mean if he was still here now he'd be an actual one. He's the one I think. And again he shouldn't be like that but let's just be feeling it anyway. The referees are a little bit in all of them. And I think that's where we're lacking. We haven't necessarily got that at the minute and I think the captain's armban for us is a tough one. It's just ironic that he's never seen him touch a ball for us but Meena feels like he could be the type of character just from what he's seen in the World Cup and what he was like with the Colombies. But then again I suppose the English thing and Silly can speak flu into English. I think that man's that. I know what you mean. But then that leads me onto my next point was and Marco Silva kind of said it the other day because they were asking him about Tom Davis. He's the right person to be the captain at the moment. But it shouldn't matter who's the captain because we should have more than one person anyway. And it's right I think more players need to lead by example. More players need to be getting in people's faces and pulling each other in. Because as a team you know you're playing footy. As a team you should all be pulling the same way anyway. If someone's not doing it then you should be telling the machine that someone put a clip on being sports, Ritchie Key's demonstrating. He knows absolutely nothing about football again yesterday with the chat about Roy Keane. With Andy Gray and Jason McHathay. He actually managed to put more than one sentence together. I was amazed. I was amazed. But they were talking about Roy Keane as a captain and a leader and worried they would grab you in all of that and pulled you through games. Ritchie Key's was like yeah but was he a good footballer? Yeah Ritchie Key was one of the best. But it was that kind of character and there isn't as many of those people around nowadays you think in the Premier League. John Terry's a tired now. He was one who I think was a lead by me example but also if it's anything going off I'm in there. Go through the teams. Where have they all gone? You know when you look now I mean Arsenal. Have Arsenal gone anyone like that? Not really. They haven't have they. You go through space. Harry Keane's captain. He leads by what he does. Golba has an everything. Is he vocal? I don't know. I think he's played against England that one as well of course. So you go through the inside. United haven't really got one. Who would you say United he wouldn't? Pogba's something. You go well. Pogba's not going to do with his ear. So there is a lack. Liverpool have got Henderson when he plays. And I would say he's probably the one. He's more in that mould. He will have a convincing company. He does a brilliant league for Manchester City. But he does it all. He's the one who will do it. So I'd say for me though at the Premier League at the minute I think Henderson is good at what he does. Because he is a referee in the game. He's in the referee's area to complain. Company does a brilliant league for Manchester City. Because I think you do need someone who will go to the referee and go what's going on. I don't get that from Jax. Jax has been a great player for us. He has. He's coming to the end but he's been a great player for us. But I think he just plays his game. He might have a little moan but he's not in the referee's face. I think he's just a good respectable footballer. I think Coleman seems like he would be that natural fit to have a go at the bottom. Again, like you've just said, the times he's won the armbann this season he's been under par. I just don't think she must have started the season very well at all. I don't know whether it's easy to say since that leg break he's not the same. But I've seen him play some fabulous games last season. The first game back he was incredible. So I think it's probably just that he tends to be a slow starter, she must have the season. And then he builds the momentum and gets better and better and better.


Okay. Okay. All right. Over to you, Nica. Okay. Thank you, Jim. I appreciate you inviting me here today to talk to the public sector SIG. Really happy to talk about Firefly and kind of talk about what's new in Firefly 1.1. I have a small demo that we can look at. I'd like to keep this, I do have some slides that I can talk through, but I'd like to keep this rather informal and more of a discussion because I would love to hear from other folks in the public sector SIG about specifically things that are interesting topics to them. So what I'd love to do is just give a brief overview of what Firefly is. I know some of you are familiar with that already, so I won't belabor the point for too long. But if folks are unfamiliar with Hyperledger Firefly, I think it'll be helpful to give just a brief bit of background. So we all are on the same page of what it is we're talking about. And then Jim, I know you gave me a list of topics to that would be interesting to the group and we can talk through those or whatever folks want to talk about and kind of go from there. So, like I said, fairly informal would love to keep it interactive as we go. But yeah, let's jump in with just kind of a brief intro. So, when we look at the, so this is a deck that we gave at a presentation that we gave at Hyperledger Global Forum, and I also have the demo that we gave there as well that I could show again in this group if anybody wasn't there for that. But we're kind of talking about the web three landscape and kind of the gen one approach to building blockchain apps for enterprises was, you know, there's this world of everything that we call web three and that includes things like consortium either public or private chains being layer one or layer two. There are ecosystems with exchanges and tokens and value and as well as all these defi apps that people are creating around these ecosystems as well so there's all kinds of things in this in this web three world. And the gen one approach was for enterprises to build a custom platform to connect to these so that there was a lot of, there's a lot of custom code that goes into every enterprise app you know you have, you have your common foundation of your blockchain and maybe the specific chains and there's a lot of open source projects in the, at the actual DLT layer, Hyperledger Fabric, Ethereum and Hyperledger Basu and many other implementations of the Ethereum protocol that a lot of great open source projects at the DLT layer. And then when you start looking at, okay, what do I need to build on top of the DLT to actually build an enterprise app. Everybody's just building a custom stack on top of that, and there's a lot of components that are common to every enterprise web three app they could build. So the gen two approach is to use a an open source platform to take care of all of these common components and build a web three app on top of that common platform to for enterprises to stop having to rebuild the same types of things for every single app they build that common platform is Hyperledger Firefly. So Firefly is what we describe as a web three super node. It is a platform that sits a layer above the blockchain, and it orchestrates both the blockchain and off chain data and flows as well to to provide an API and tools that developers are already familiar with even if they're not web three developers even just regular web two developers like like I am or used to be. It provides familiar things like like REST APIs and web sockets and things like that that developers can use to leverage these building blocks that Firefly has in it already that are these common patterns that we see in in every web three and I'll get into what some of those are in just a little bit, but it's this platform that the developers can use to easily build blockchain apps and not have to keep rebuilding the same plumbing and infrastructure over and over again. So, here's this picture for me helps kind of put that into perspective so you're down here at the bottom. Hopefully you can see where I'm pointing with my mouse. You know you have you when you start thinking about okay I'm going to build a blockchain app well I'm going to start with the blockchain and I'm going to start with a smart contract that does the business logic that I need to do. And then you know that that makes sense that's kind of where everybody starts that's down here at this layer, like I said tons of great open source projects down there already we're not looking to Firefly is not looking to be yet another blockchain. It's looking to provide functionality on top of that. Once you start down this road of trying to to build an enterprise app though you know you get your smart contract and then you begin realizing actually there's a whole bunch of stuff that I can't put on the chain either the data is too sensitive, or it's too big, or it needs to only be shared with certain parties and everybody, or maybe there are a lot of a lot of enterprises have GDPR requirements where they need to actually be able to delete the data itself. And obviously you can't delete data out of a blockchain once it's in there. So, so people start realizing okay there's, there's this mix of things that need to go on the chain things that need to stay off the chain and I need something to manage all of that for me and to to create these connections between on chain data off chain data to be able to transmit to broadcast things to to other parties if this is a consortium network, or to privately send data between members of the consortium. I need something to be able to manage tokens whether they are fungible or non fungible tokens tokens are are an essential part of just about every blockchain app. So there's all kinds of these pieces and this is what we see in the all these these yellow blocks over here. And so, so rather than rebuilding all of these pieces over and over again Firefly is this platform that hey we've we built all this stuff. It's open source, you can extend it. It is, it's free, and it looks to be the, the, the go to platform to build a web three app on top of. So, this lets companies focus on, you know what's, what is the thing that's actually going to deliver value for my company. And that's really what enterprises are concerned with the end of the day is is the business value. So, Firefly, let's companies focus on not building plumbing, but you know what's what's the actual application what's going to deliver value to my business and to my customers and focus really on that piece rather than all of the rebuilding all these building blocks over and over again. They can just use Firefly. So, hopefully that kind of helps put it in perspective. Here's a view of the, the different things that are in Firefly. This is not an architectural view per se. So as an engineer, I kind of look at this ago, it's just a bunch of boxes. But to, you know, to, to somebody who wants to look at you could what what value does Firefly provide that's kind of what this this diagram is describing so that the three main pillars of things that Firefly allows you to do are build apps flows and digital assets. And so Firefly has, it has, it can act as an API gateway, we call it a web three gateway. And we'll talk about kind of the different modes that Firefly can run in a little bit. It has things that can generate API dynamically from smart contracts. It has a fantastic event stream API that can index events on a chain and provide reliable either web hooks or WebSocket subscriptions to deliver those events to your application. And that event bus is pluggable as well. This will probably a common refrain throughout the entire presentation but just about everything in Firefly is pluggable, which means there's, there may be more than one option for the implementation of it, including the blockchain itself. And blockchains have plugins and connectors in Firefly, which means that the actual core of Firefly which we see here in the middle is strictly speaking blockchain agnostic. It talks to a connector that knows how to talk to a specific chain. And there's actually one of the really new thing, the new exciting things in Firefly 1.1 is a framework to build new blockchain connectors and we'll talk about that a little bit.  If it's compatible with EVM and JSON RPC, it should work. So, and there's also kind of a starter kit for Corda as well for building Cordapps that use Firefly as well. So like I said, there's plugins for everything all the way from which type of database you're using to the event delivery bus all the way to the blockchain that it's being used as well. And so it's a very, it's a very pluggable, very micro service type architecture. That was a bit of a tangent from from this particular diagram, but getting back to the diagram. Sorry about that. So apps flows and digital assets. So we talked a little bit about apps flows. I kind of hinted at earlier so that there's two main modes that Firefly can run in one is Web 3 gateway mode where Firefly is sort of my my API gateway to the Web 3 world. So I can use it to interact with public chains or maybe a private permission chain, but it's just my app talking to a chain. The other mode that Firefly operates in is what we call multi party or consortium mode. And so in this mode, you may have multiple organizations that have come together they formed a consortium and they have agreed that they want to use blockchain to integrate with each other. So they may be competitors in the space that they're in maybe it's insurance or maybe their healthcare providers or maybe their financial institutions. So they may be they have varying levels of trust of other parties within the consortium but they need to perform business transactions exchange data exchange value. So Firefly allows you to build these. It's rather complex flows relatively easily with its API building blocks. So this includes everything from like, for example, I need to have a piece of data that I need to broadcast to everyone in the consortium. Or I have a piece of data that I need to share privately with one member of the consortium or group of members in the consortium. So Firefly allows you to do things like I need to transfer some value so this gets into the third category here digital assets. There are great APIs for tokens in Firefly, like I said, both fungible and non fungible. And again that this is pluggable so there there are connectors out of the box for ERC 20 ERC 721 ERC 1155. But again it's pluggable so if you have a custom token contract, or some other ERC standard that you want to use with Firefly. You can create a token connector for that as well. But these digital assets can also be linked with flows so you can, you can transfer for instance you can transfer a token and associate data with that token transfer that could be either broadcast to the entire network or it could be. I'm going to transfer this token from for myself to another party of the consortium and then privately share some data with that other member of the consortia as well without disclosing that piece of data to the entire network, which is really powerful. There's lots of great tools that go along with Firefly there is a command line interface that helps you get up and started on your local machine to kind of give you a development environment to build on. There's an SDK right now for for Node.js TypeScript and more SDKs to follow, but that that one's there right now and it works great, great to get up and running really quickly building an app on top of Firefly. And then there's just a really great API that has pretty thorough documentation with a swagger UI that you can play with right in your browser. We can look at that in just a little bit. The whole thing is designed to be run in a modern cloud native infrastructure environment so Kubernetes is kind of the go to deployment model for Firefly and has Prometheus metrics built right in. So lots, lots of great stuff for for developers and operators to run the system in a really modern cloud native way. So, I didn't talk at great length about the Firefly core but the Firefly core is is one of the really important parts of everything so Firefly core is one of the microservices that runs within Firefly. And it's this orchestration engine, it's sort of the thing that is connected to all the other things. And so it is talking to a shared storage bus, a blockchain and a private data bus as well. Right now the out of the box implementation for shared storage is IPFS. There's a private data bus is a peer to peer HTTP with mutual TLS connection. But again these are all pluggable so they can be, they can be extended enhanced or used other implementations as well. But Firefly core is doing all of this work of coordinating all of these things that are happening both on chain off chain. It's tracking events indexing things that are happening on chain and providing an API for an application to use to query you know what what is the state of everything that's on the chain currently. What events have happened on this smart contract that I am concerned with. An application can also use Firefly's API to submit transactions to the blockchain and transfer tokens and all this great stuff so the Firefly core is really the the piece that connects all of the other pieces in the Firefly architecture together. All right, so I will, we'll kind of move on through I'll quickly go through some of these slides I won't spend a ton of time on them, because I kind of want to. I want to make this interactive so some of the some of the cool features that Firefly has you can give it a smart contract it can generate an API for you. This can be so you, if you have an Ethereum smart contract you can give it the API, and it will generate it for you if you have a blockchain that doesn't have a application binary interface format like like Ethereum does, for instance, hyper ledger fabric doesn't have a standardized way to document all of the inputs and outputs of all the functions and events that are on a smart contract. You can write the Firefly introduces a blockchain generic blockchain agnostic format called a Firefly interface or an FFI, which is a way to describe your smart contract to Firefly, and it can build an API from that as well so there's a built in container if you're using a blockchain that has standardized way to describe a smart contract and if not you can you can write it yourself. We've talked a little bit about how Firefly is a web three gateway, and it has it has all kinds of stuff that just there's some really hard problems that are solved in Firefly and in the blockchain connector level that just allow you to let Firefly take care of that the really complicated stuff of like keeping up with the chain or resolving when maybe it's a public chain and you get maybe conflicting next blocks and which which one is right which one wins. You know your blockchain node is sometimes if you're using a blockchain note on a public chain is sometimes unpredictable. And so, so the blockchain connector handles all of these really hard problems of you know keeping track of the current state of the chain indexing a certain event type on a smart contract on that chain and going through the history of all the blocks and building that that rich queryable history and making that available to easily query via Firefly's API. We've talked a little bit about data flows and the different sort of communication buses that Firefly has, and this is comes in really is really powerful in a kind of this multi party consortium mode that Firefly can run in where you have multiple different organizations that want to communicate over a private data bus or to share data throughout the entire consortium and and also using the blockchain as well. Firefly can manage digital assets at scale, we call institutional scale or at enterprise scale. So there's there's great API's in there in built into Firefly for managing tokens, whether they're fungible or non fungible. There's a great this is a screenshot of the Firefly Explorer which we'll look at in just a minute that can kind of show you the tokens. Firefly core is a, like we said this orchestration engine for event driven flows. I'll go over some of these because we've talked about them. Just a bit of history on the project. And then I'll just briefly touch on some of the things that are new in one dot one and then I'll wrap up my slides here in a second. So, so Firefly so I work at Kaleido as Jim mentioned in his introduction so Firefly Hyperledger Firefly came out of sort of the years of learnings by Kaleido and the original code base was donated to Hyperledger foundation in 2021 for funding to the Hyperledger foundation from Kaleido. So sorry I was hesitating there because I was trying to make sure I got my dates right yeah so. So June of last year, Firefly launched as Hyperledger lab. And then in September it was promoted to a project. We launched one dot oh in April of this year and one dot one was just announced at Hyperledger global forum, a couple weeks ago at the beginning of September. And the project is it's a microservice architecture so it's 19 different repos so there's, there are a lot of places if you're interested in getting involved, there's a lot of places that you can jump in and get involved in the project. There is a variety of languages that are used from Golang to TypeScript. There's even a bit of Java here and there as well, not very much but if you if you want to do things with quarter you're definitely looking at using Java there. So it's the code base has grown to 265,000 lines of code, roughly, when we launched one dot one. But really it was, it was years of learning and iterating on this idea of like a lot of blockchain apps that we were seeing built at Kaleido were using the same platforms over and over again, and it really came down to a set of fundamental building blocks to build a web three application, an enterprise grade web three application. And we said wouldn't it be awesome if there was a platform that already did all of this for us that we didn't have to keep rebuilding the same building blocks. And wouldn't it be even more awesome if that platform were open source, so it gains mass adoption throughout the world. And just, and the community can contribute back to it and enhance it and grow the platform as time goes on as well so that's that's kind of where where Firefly came from it came from these years of learning and seeing these common patterns and and the desire to open source that and create a standard that anybody can build a web three app easily and quickly against some really cool features in one dot one it's by far our biggest release since one dot oh there's a. So this distinction of gateway mode and multi party mode are something that's new in this version, and along with that, so a bunch of these features combined to allow some some really awesome new functionality like being able to connect to public chains and exchange tokens on a public chain. You can also connect to multiple chains at the same time that was one of the things that Jim mentioned specifically that he wanted me to talk about here today. So to build flows that actually bridge multiple block chains so Firefly is is not by definition a token bridge in and of itself so it doesn't necessarily know the details of a particular contract and how to bridge a certain type of asset from one chain to another chain, but Firefly gives you the connections to connect to multiple chains at the same time and you could build the logic to create a bridge using Firefly and Firefly provides API is to do that really quickly and easily. So there's there's also a new blockchain connector framework and this is what one of the other talking points that Jim wanted me to touch on was, you know how to connect to different types of chains. The blockchain connector framework is a thing that I'm really excited about it's it's a really nerdy low level thing so if you're not a back end engineer you you've made just your eyes make loss over at this and that that's okay but for those of you that are interested in blockchain protocols and extending the ecosystem. The blockchain connector framework is a. So there's there's two things one is a an API contract, not a smart contract but an API contract between the blockchain connector and a specific implementation of a blockchain connector. So, so what does that mean so there's a go lang library that we it's, if you look it up and get hub it's called Firefly transaction manager, maybe poorly named but it started it evolved throughout its lifetime. Firefly transaction manager is a go library that if you want to build a blockchain connector and go, it probably has 80% of all of the logic that you need already implemented to build a brand new blockchain connector, regardless of what type of chain you're connected with. And the remaining 20% is like, how do what what is the syntax of submitting a transaction to the chain, the XYZ chain, or what is the syntax for querying a block number or a range of blocks on XYZ chain. And so it provides this interface that a developer can use to say hey I want to plug XYZ chain I don't know if that's a real chain I'm just making it up. I want to plug XYZ chain into Firefly. And just take this go library and it has all of this really complex stuff of transaction management, nonce management, retry logic, gas price estimation, and, and sort of this this managing the policy around like how how do I handle transactions when things don't go the way I hope they do because that sometimes happens especially on public chains. So all all the logic around indexing events that are happening on the chain. Making sure that we have enough confirmations on a transaction to be confident that the state is final of certain transaction, all this stuff is implemented in a blockchain agnostic way inside the Firefly transaction manager library or the blockchain connector framework and it's just up to me as a developer to to write the implementation of like okay well how do I query this chain how do I submit the transaction, how do I, how do I check for the current price of gas and these sorts of just the more low level things. And I'm really excited to see where where this goes. I'm hopeful that some some groups within the broader blockchain ecosystem will pick this up and build new connectors we've been talking to some already that are interested in building a connector for several well known public chains so it's really exciting to see where this will go and hopefully will be a huge head start for people as they're looking to build more blockchain connectors and enhance Firefly. So, like I said it is a, it's a hyper ledger project so it's open source it's Apache to licenseable. If you're familiar with hyper ledger it's it's everything that hyper ledger is, and it is it is a hyper ledger project. So so that was kind of the end of that deck and then I can go into a demo. I think what I would like to do though is just kind of pause and that we're kind of with about halfway through the today's meeting. So I think now it's just kind of a natural point to pause and ask if there are questions, and maybe we can just have a bit of dialogue and if there are specific areas that people are really interested in Jim maybe you can kind of provide some pointers of maybe areas to dive into a demo or more just kind of open ended discussion would would love to love to just hear kind of where the group wants to go from here. So, yeah, first of all, they go thank you very much for where you've been so far in about 20 minutes. I think if I had another hour I'd ask you to cover the history of the world, you have a high rate of output which is awesome so there's a lot here we're going to have the recording of the slides to post up later to the other groups as well for reference which is important, but I can say on two sides here one I was in Dublin I went to lab that Nico did on firefly one one. And the key is the labs they put together were actually really well organized for beginners because I was new to firefly so that was nice. And I'll say though is if you go back and have time later look at the slides. If you've ever built real blockchain apps. And I had either built, you know, probably three or four by now that are on different chains fabric and so on some other ones. And if you look at building that whole solution. So as an architect that had a chance to look at probably a dozen more in detail as well. If you go through his slides. There isn't a lot that they that's outside of what I call the scope of firefly that you have to build. And that's actually a huge, huge win. So, actually, and I wanted, I'll grab something on my end I'm a cheat. So, one second there's a, there's a slide I'm going to talk to this is sort of a, it's one he showed. I'll just flip it up real quick. So let me share my screen. Well fast. It's this. So you can see my screen right. If you look at this slide that need to show you right on the left. There's a lot more going on, honestly, on the left hand side if you're building a blockchain app, then just what he shows here. There's a lot more actually.  So if I look at my own company DTCC and say hey we've got blockchain apps to build. And I'm saying okay.  And the things down here, I'm still building the same way so Nico jump in and correct me wherever I make a mistake here but I'll say whatever I'm doing on the blockchain itself. The smart contract definitions and so on that part of the setup is still done down here. It's the rest of this infrastructure that in a sense, we're saying this is potential game. I'm actually looking and this is where I need your help me better pick it up in a little bit I'm going to ask you is we've got two scenarios you're either building a brand brand new blockchain app, or you're taking an existing application that I actually can think of a couple I've got and saying hey you know what we built from a certain way, they're okay, but they're not really well architected. And the thing I'll say by firefly. The thought behind it is quite strong from an architecture perspective. As Nico said there's this concept of everything can, in a sense become visible if you will, to the applications and services that need them on the event bus, which is a huge benefit to building a solution. The other benefit obviously as you can see he went through the components slide about all the different services, because they're different services. It means, and as he said a lot of those are pluggable that those services generally have a conceptual interfaces it's not real interfaces, which is why in many cases they're pluggable so in my case if I want to. Yeah, I'll say I'm looking at existing apps we built in blockchain that, for instance, don't use an event bus, or don't have a common architecture across different blockchain platforms we're trying to connect. If I said okay, what's what for me is the value point for bringing firefly into a next version of one of those apps to replace what we've already done. I'm going to call it an integration challenge on the quote the brown teal kind of an app that already exists say okay, my blockchain layer, my smart contract layer that's already supported by firefly then I just have to use the connectors share enough, but I will have to in a sense bring over or in a sense modify some of the stuff that firefly would generate so that's my theory that Nico can correct on a brownfield that by greenfield that. I think where the app doesn't exist and I'm starting out from scratch, also want to go through that scenario so I'll push it back to you. And by the way, I'll say last point I'm going to make on the slide. Yes, this left hand stuff is available, and even more in the component diagram that Nico showed on the right hand slide, if it's a greenfield that yeah I'm going to benefit from the bulk of this. The existing app or brownfield that will say, well, I'm going to have to refactor some of the stuff that I will want to reuse some of it I won't. But I'll let firefly kind of build the framework, and then choose what I have to modify in here so there's still more work to be done in the side. And then a greenfield that I would say but the idea is, even if I realize quite a small section of this potential. That's a massive net gain in three areas in time cost, and improve quality because they didn't have to write the code. There's less quality work to build a quality application there's less testing and debugging for the stuff that already works as standard firefly components for sure. So those are the potential gains, even if I don't realize the entire purple block there as a net game for my organization. So with that, let me flip it back to you Nico I'm going to take a look at the chat and see some of the questions there but give me the thing that I'm most interested I guess is first walk me through from your perspective. Say I have a really trivial app. I think the lab that the NFT things we had one is, you know create the NFT, and then we, you know we're doing I think transfers of an NFT sales if you will whatever redemptions and so on. If you were building a new app, and you can use, I don't care if you use a theorem of fabric is your base blockchain but walk me through what I call, from your perspective, the right flow. Given firefly as my tool set what would you see is the right process to design that at the start at the smart contract level do I started an application level with in a sense contract services. How does that flow work for a small brand new app that I do building. Yeah, yeah, great question and so I think. And I think the initial starting point is actually going to be the same for what you described as the brownfield application as well where you want to refactor an existing app to use firefly. And I think actually the right place to start is really just trying to wrap your head around what does like what are the actual functions that firefly gives me. What are the building blocks and so I'll just briefly. I see there's a lot of great questions in the chat, I will address those in just a minute because I think there's some great stuff to discuss there but I'll take Jim's question, and I'll just kind of walk you through real quick. This won't be at a speed that you can follow along in real time but if you want to later. You can go back and watch the recording, but just to get started with firefly. You can get started by going to the docs, and in the docs, there is a section on understanding firefly and just what it is but I personally learned best by doing, rather than reading is good and I need reading as well but doing is the thing that makes it real for me. So for all of the people who learn by doing out there there's a great getting started guide that walks you through how to set up the firefly command line interface, which is the thing that will run firefly on your computer and so I think really the best way to get started is like to just get your hands on it try it see what it does. Look at your trial the different functions in it so firefly command line interface will. You can download a binary build from GitHub. Here's the latest release you can just come down here pick the right one for your operating system and CPU architecture. You can also use go install to install it as well. But once you once you install this. It's really easy to set up firefly on your computer. It's a little diagram of everything that will set up for you, it's going to use Docker. And then you can name your stack, you could pick the number of members, the default is to run it in a multi party consortium mode. If you want to run it in a web three gateway mode, there are command line flags for that.  So that gets you up and running. What does that give you so it'll give you a all it'll give you firefly and all of its services for say I picked three members here in the docs. So it gives you a web UI and a sandbox UI for each one. The sandbox is a great place to start. I'll actually hop over to I have a, I can get this zoom window out of the way here. I have firefly running so here's my here's my firefly explorer, and I also get the the firefly sandbox. And so we talked about kind of the three pillars of firefly kind of the three main buckets of functionality. And those are messages tokens and contracts so I'll start with messages because like it sounds really basic. It is it is it's like many of fireflies other functionalities are built on top of its messaging functionality. But there's a lot that you can do with it and so I would encourage people as you're thinking about the firefly paradigm. It's it's an event driven that most most blockchain apps end up needing to be event driven just because blockchains are event driven and so there's a lot that you can actually accomplish just through using messaging and and the messaging is backed by the the chain itself so most people immediately think oh I need a custom smart contract to do business logic XYZ. You can do that and I'll get to that in just a minute but I would encourage people to kind of backup and just like take a look at what firefly does and all the functions that it has built in and and see if you can map those to the business constructs that you have in your app. Many times what we find is that the fireflies built in, it has a smart contract built in and I can describe what that does in a little bit but it's built in functionality between messaging and tokens. It's built in more than enough for maybe maybe you need a slightly customized token contract but you don't have to go right like a completely new thing because like getting the smart contract layer right. Getting it secure getting it so that it can't be exploited getting it so that it can be upgraded properly in the future like those are those are pretty hard problems very specialized development as well. It gives you that control if you want that level of control and you need it but it has a lot of really powerful functions built in so some of the things that I would encourage people to look at our broadcast messaging so this is like I want to send some data to everyone in my system. It can be a string. It can be a JSON object that JSON object can so I can define a data type in my network so I can define like this is what the here's the JSON schema for a customer record. It can be broadcast like I have a new customer record or a new order that was placed in the in the system. You can define these data types and everyone agrees okay this is, we all understand what we are talking about when we say a customer record or an order number and then you can you can have firefly validate the message against that schema later. I could just broadcast a file that can be a binary file it could be an image PDF document. All of the payloads of these messages are going to be saved off chain they're going to be saved in IPFS. And what goes on to the chain is the hash of the actual message. And so all the other firefly nodes in the network will will an event will be triggered when that new data is pinned to the chain when its hash is put on chain. So they become aware of it and then they can go look up in IPFS the actual payload off chain of whatever that document or that JSON payload that was broadcasting. Just like broadcasting, you can also send strings JSON objects or binary files through private messaging as well and this the recipients here could be a single recipient or it could be a group of other organizations within the firefly network. So there's, you can optionally pin the data to the chain, or you can keep it entirely off chain as well so that's another option just for if. Maybe you have a part of your application that actually doesn't or shouldn't use blockchain at all there's there are varying degrees of like how much you want to use the chain in all of this. Let's go back to the tokens tab. This particular firefly node sandbox is not set up to actually do tokens here so I'm not actually going to push the buttons but if there's a token contract on chain already. It's just really easy to connect firefly to that I can put in the contract address I can tell it is it fungible or non fungible, and you know what block number, you want to start indexing I'll just hop over to the the explorer UI and so you, I do actually have a so I'm going to switch names I this firefly node is connected both to a private fabric consortium and a public polygon test net as well so if I switch to the polygon namespace, and then I hop over to my tokens tab. Let's see, let's see in the last 30 days, we'll buff this time out so this was a token contract that I deployed during global forum. I can see, I minted 100 tokens, probably right before, probably this is probably the day before the presentation, I transferred some of them during my demo in real time. And I think I minted some more during the demo and then actually just this morning, I said hey I should make sure this stack is still working so from a metamask wallet I transferred 10 tokens back to the wallet that firefly is using so really, really cool, really easy to use token capabilities here. The really powerful thing is that firefly is aware of all these things that are happening it's keeping track of the balances of all these tokens so that it provides a really easy to use API that I can just query to hey what's the balance for for this account. What is the, what's the entire history of this NFT token and all the times that it's been transferred. The lock chains themselves are not particularly good, or optimized for answering some of those questions quickly normally so so firefly provides a lot of functionality around now. So, I apologize if this was like just just a segue into my regular demo but getting back to Jim's question like I think just kind of to start where I would start is like just just explore firefly use the sandbox use the. You can go a swagger UI for all of the endpoints on here. Play around with this you can you can post here to define a data type instead of doing it through the sandbox if you want. As you're doing stuff through the sandbox, it's dynamically creating code samples that you can use if you're writing a Node.js or TypeScript app and you want to use the firefly SDK it's generating the code on the fly here that you would use to put in your application to do the specific operation that you're doing here in the sandbox so really powerful tool just for learning about firefly. But it's really this exercise of like just understanding what what are the building blocks that firefly gives me and then sort of mapping that to like what are the things that my business application, my, my business logic flow needs to do. And, you know, trying to see like, do the building blocks that have been provided cover all the functionality that I need or maybe I do need to go into the kind of the third door here of custom contracts and then that's okay firefly. And let's you do that as well. You can use firefly to interact with a completely custom smart contract. And you get all of the rich indexing and really easy transaction submission features of firefly. So, so that's where I'd start. And I think the same is true for building a greenfield app or refactoring an existing app is just sort of this, this mapping of like okay what, what does firefly do and like how can I, what parts of my application can I leverage to do that and hopefully it should be a lot of it. And it's, it's the type of thing to like if you have questions about it. Come, come ask us in the in the firefly discord channel we love to chat about this type of stuff to help people brainstorm like, how can I accomplish XYZ or fill in the blank with with firefly. We'd love to chat about myself and the other maintainers are there and more than happy to take specific questions of like how to implement a certain type of use case in firefly. Okay, Nico really quick. I, we're getting closer toward the end but we've got a couple of questions in the chat. If you want to hit, I'll say, one of them says, can the flow support a multi L one chains layer network, not a consortium but Yeah, absolutely so so the flows are really, it's firefly allows you to build the flows in your application so we've had questions of like what does, can you do BPM and or with with firefly and the answer is like firefly itself doesn't do BPM and but It, it gives you so it gives you an API and it gives you an event bus that are really easy to use either through web sockets or web hooks and allows you to build the off chain logic of like okay this. This event happened here now I'm going to go do this operation on another chain whether that's another L one chain, or whether it's a private chain. And so, so, so, so the answer is yes firefly allows you to build that functionality absolutely and it doesn't matter whether the chain is L one L two, whether it's public or private firefly can connect to both of them and give you the events as things are happening on each chain and allow you to submit transactions to either one. And one other thing is a question about fabric but I'll just say in general the concept of fabric has a lot of features in its own network, if you will, that they built into it that some of the other blockchains don't by default. But that said, if you think about firefly it's a layer above. It's the application layer over your blockchain network as you showed in the diagrams. So what that means is to have a common architecture and a common set of services across multiple blockchains. In some cases you like fabric is a good example you wind up implementing a feature that fabric already has differently in firefly. Right. So the specific question really talks about the fact that in fire, why it says can we use firefly in place of the gateway SDK that is already provided by fabric to get to our contracts and I think the answer to that is yes, through the fabric connector. There's also an fabric they give you very nicely something called a certificate authority manager that's actually pretty powerful. So if your organization doesn't have one you can use the CA manager and fabric directly to you know create certificates but I think in firefly I'm going to guess we have something similar to that is that a fact. So, yeah, so just a couple of things there. So we're very aware of, and some people have mentioned like oh well if you're blockchain agnostic then your least common denominator and like I'm very aware that that is a potential pitfall that the that the project could fall into. I, I don't think we are like, that's not the road I want to go down. And I don't think we're going down that road. I look at it from from this from the perspective of like there, there is a set of business problems that I need to solve. And what is what's the common set of functionality that I need from any chain. And, and looking at it sort of from the other direction rather than like, oh well, because I built on firefly I don't get feature XYZ from from the certain chain that it's also worth saying like there's nothing stopping you from going and using a specific feature and a specific chain by by talking to that chain or the blockchain connector for that specific chain as well. So with regard to the fabric gateway SDK and the CA to firefly uses these things behind the scenes. There is actually a specific open issue to upgrade to using the firefly. Sorry, the fabric gateway SDK, we're using the old SDK right now because right firefly is still compatible with fabric. Yeah, 2.2 LTS. And yeah, so we haven't, we actually haven't upgraded to that because we don't want to drop support for the old version yet. But but but firefly and the specifically the fabric connector inside firefly will be using the gateway SDK. So can you use it in place of that. It's the idea is that that that it is the platform that you can build your app on top of and it doesn't like you could actually switch chains later. If you build your app specifically to use the fabric gateway SDK, you can't switch to using an Ethereum chain later. And that's, that is one of the powerful things that fireflies that if you build to fireflies API, you can use any of the plugins that firefly supports. Yeah, and actually you hit. Well, what I guess I really like compared to other solutions that I'm aware of. I'll say is the fact that I have the choice the control is on my end, so that I can say oh cool Jim wants to build across three different blockchains and I'll just use firefly quickly out of the box and follow what I can do there but what I really like is I have the flexibility and real enterprise apps do need that to say hey I have the special feature maybe in fabric as an example that I need to go down and use that and I can say well I built the app to start with and connected to to fabric that way, but now I'm going to actually use the features in fabric directly that I need, you know in some new release as an example. And so that's a good and the only other thing I'll say is the challenge that you guys have on your end, which is in, you know, I don't want to be the guy. Well I'm glad I'm not the guy that writes the fabric connector let's put it that way for you, because that guy will have to come up with some smart answers so he'll say oh yeah I'm the brilliant guy that figured out how I can support both the old and model for fabric to to and whatever is to five or something like that with the gateway SDK that that opportunity is really up to you know your team collido to figure out how do you how do you want to design those connectors. But certainly that's, I like the fact that it's both simple to use as you said common and I can leverage the benefits if you will have any specific blockchain just by in a sense going to that level and doing a little more work on my end. Yeah, yeah. A couple other great questions here in the in the chat I'm going to try to hit some of these rapid fire does firefly support token definition management on fabric. The answer is it could we, somebody would need to write a token connector that talks to fabric in order to do that but it's it most certainly could. We just don't have a, there has not been a demand for or anybody really asking for a token for fabric but it most certainly could commercial adoption so far. I wish I had more time to talk about this but yes there is there's a good amount of commercial adoption, especially within. So the company that I work for collido runs firefly as a service on top of our blockchain as a service platform and consortium as a service offerings as well. We have many different customers in different industries. Off the top of my head, I'm an engineer so I have trouble remembering which ones I can talk about which ones I can't but industries from from healthcare to insurance to quite a few different financial applications well there's there's there's quite a bit of commercial adoption already and new solutions that we're working on all the time. Yeah one one big area I do want to hit that's important, not only to my company but obviously a lot of people in the chat to. There's a bunch of what identity frameworks based on self sovereign identity kids verifiable credentials and all that and we're trying to figure out in a sense what the smart way to integrate to one of those networks might be as an example. So I don't know in the local the work that flight is already doing, I'm sure somewhere they were to take a look at those kind of projects and I don't know if there's any kind of a guidance document that you might have or a page that talks about if you're running an identity network could be sovereign could be various could be a bunch of different ones out there. So with those, how would I map an identity credential framework like that into the firefly world without having to have you build a whole new version to do that. Yeah, yeah, so so great topic. Unfortunately, that's, I think that is probably multiple sessions of. So I noticed there was another question in the chat. Kyle mentions he's coming from Hyperledger Indie Aries and on. I think one of the big takeaways from this year's Hyperledger global forum for me was just kind of the momentum around self sovereign identity and the, the work that is going on in Indian Aries in Hyperledger. And the need for the folks, the firefly maintainers to get together with some of the folks on those projects and talk about like what, what can we do to integrate these things, the identity. I'll refer to it as the identity story in firefly is not done yet. So there's, there are, there's places in the code where it's sort of stubbed out of like, you know, this is where we plug in an identity service. It's not complete yet. And I think that is an area that that we really need to collaborate with some of the other hyperledger projects as well. Yeah, and I will say my company is one of those we have multiple projects that would fit that SSI model and would want to benefit immediately from firefly so that's a common thing. Cool. So support for Kubernetes. Yes, that's how we run it in production would definitely recommend it. Firefly support multi org on multi network. Okay, so just real quick on on how the structure of this stuff so firefly has a concept of a namespace. So a namespace is a set of plugins within firefly. So a namespace either runs in multi party mode or it runs in gateway mode. So, you could have so so like in my in my environment that I just showed a minute ago I have two namespaces configured I have one that's a fabric network and I have one that's a public polygon testnet. You could have there there could be overlap between you know an organization could be in multiple namespaces. And so, so yes and no but it's just sort of this this grouping of like in this namespace I'm talking to this blockchain I'm using this database I'm running in multi party mode. And I have, I have this IPFS instance that I'm using for this namespace and over here, I have, I may have the same chain. I may have and I may be running in a different mode, or it could be a completely different chain it could be a different could be public IPFS it could be a different database. So there's sort of the groups of all the plugins in firefly are kind of roll up into this namespace concept. Yeah, and so the bottom line on that is I'll say that the concept is ABC, or as an organization could belong to two different networks within firefly, in a sense, and without any problem at all because those are different namespaces for sure. Yep. How does one create a channel like in fabrics your life through firefly so firefly is not an infrastructure management tool so it's it is not. It's not in scope for firefly to manage the actual blockchain. So, so things like firefly doesn't actually deploy a contract for you. Firefly itself does not actually set up a blockchain for you. That being said the firefly command line interface is a developer tool that will do some of those things for you on your local machine. It does. If you want to use fabric it will set up a relatively trivial fabric network on your machine. It can deploy smart contracts to chains on your machine. It is not a production tool though so I'll just say that like I think a channel is how you would normally create a channel in firefly using right your commands. Sorry, in fabric not firefly to too many hyper ledger words. Yeah. But no fabric you're right fabric has many fabric as a tool. There's actually a very good if you're looking at fabric there's a brand new what they call full stack fabric tutorial they just built that does deploy directly to Kubernetes as well. You know if you're looking at really fabric, go take a look at that tutorial, come back and take a go through the getting started on firefly to figure out how to how firefly works and can in a sense build something quickly. But the key thing is that the base fabric in a sense is easy to do in many fabric. Second thing is you're going to build your contracts over the last thing I want to look back on the language piece. You said we have no JS type script or SDKs available do I have a Java SDK available as well. There is not one currently available but would love if somebody wants to contribute one there's our approach has been to generate as much of the SDKs we can from firefly has a pretty comprehensive swagger definition that is part of firefly. Like, I have a love hate relationship with generated SDKs. On the one hand, they're, they're really great for being able to stay in sync with the API. Sometimes the user experience the developer experience leave some to be desired so. Yeah, that's been our approaches to use the swagger definition as much as we can but also still provide a good developer experience as well. Okay, excellent. All right. And then the other thing I'll encourage people. Nico talked about starting with the getting started in fire fly which I agree with that very much. But as somebody else who has to answer more questions on architecture and I'll put how firefly might work. I was impressed as somebody who has managed products before when I looked in the documentation so the concepts you see in the little bubble diagrams on the slides. Guess what there's actually good doc behind that if you dig into it so like the event bus and how that works and how it integrates. I'm really excited to say, oh cool, I can literally go as a architect I can grab that and just throw it over the fence and say here, this is how it works. And it looks funny it looks like exactly what we want to build anyway so it's kind of nice to see the documentation at the level you have it. So that's great. With that I realized, you know, unfortunately we could go on for only about four days to answer more questions, but we don't have that time so I do want to thank Nico very much. I'm really excited that collido has done this phenomenal framework, really like the clean architect not only the architecture of what they're doing, but also the fact that they say these are the boundaries so we allow you what I call the interface to talk to any blockchain would give you connectors to start with those kind of things so it's really a well thought out solution for sure. Obviously, I intend to use it many many times within my own company so hope the rest of you will follow. Certainly, Nico collido is going to produce more stuff on this, and I would also say the community is also not just myself but many others in the community will properly also start sharing some of our experience on Firefly. So with that thank you again Nico it's been awesome. I've got to stop the recording at this point. All right, back to date everybody else. Yeah just just real quick. Thank you Jim. Thank you everyone for inviting me here today. I will share the slides I'll send them to you Jim and then you can post them to the sig page. If you want to stay in touch after this hyper ledger discord come find us in the Firefly channel and happy to chat more about Firefly there. Thank you everyone really appreciate it. Thank you so much. Thanks everyone. Have a good day.


Welcome to this EuroCrip 2021 presentation on one-way functions and malleability oracles, which is a talk about hidden shift attacks on isogyny-based protocols. This was joint work together with Peter Kutas, Christof Petit and Charlotte Weidkampel. In our work, we show that for overstretched and unbalanced parameters, a quantum sub-exponential attack on SIDH exists. I'll get back to what this means in a couple of minutes. The attack uses a reduction to an injective abelian hidden shift problem. For seaside and isogyny-based protocols based on ordinary curves, it is known how to solve the underlying problems in quantum sub-exponential time via such a reduction by the results of Charles Jauh and Sukharov. Yet a commonly widespread belief was that the algorithm of Charles Adol does not apply to SIDH. The argument was that the algorithm relies crucially on an abelian group action and therefore no variant of it would apply in the SIDH setting. Our work shows that for specific parameter choices, this widespread belief is false. However, let me add a disclaimer right here. The attack does not apply for balanced SIDH parameters as they were originally suggested by Jauh and Tefio, nor does it apply to Psyche, which is the isogyny-based submission to the NIST standardization process. Instead, the value of the paper consists in showing that a completely different attack vector exists for inadequate parameter choices. Let's start with a quick recap of what isogenes are. Let E0 and E1 be looked at curves defined over a field K. In cryptography, we are usually interested in those curves being defined over a finite field. An isogenes is a non-constant rational map between two curves that fixes the identity or equivalently is also a group homomorphism. Recall that elliptic curves have a group structure on them, so this in particular implies that the kernel of an isogyny is a subgroup of E0. However, the other direction is also true. Every finite subgroup of E0 defines an isogyny. Indeed, we have a one-to-one correspondence between finite subgroups of E0 and separable isogenes, which is the kind of isogyny I will be mostly talking about in the following. For these isogenes, the degree of the isogyny, which is the degree of the map when written as a rational map, equals the cardinality of the kernel. This kernel of an isogyny determines the image curve up to isomorphism, which is why it makes sense to write the image curve as the quotient of the starting curve and the kernel up to isomorphism, and elliptic curves that are isomorphic share the same J invariant, which is an invariant that can be efficiently computed. Since for every isogyny there exists a dual isogyny in the opposite direction of the same degree, this gives rise to an undirected L-isogyny graph, where the vertices are J invariants of elliptic curves and two vertices have an edge in between them, if and only if there exists an isogyny of degree L between those curves. Isogyny-based cryptography is one of the candidates for post-quantum cryptography. The core problem of the area is to find large degree isogenes between super singular elliptic curves. If you consider the previously mentioned isogyny graph, this could be interpreted as a pathfinding problem, where you're given two vertices in the graph and you have to find a path connecting them. Most isogyny-based cryptosets systems, most famously SIDH, are based on variants of this problem or slide realizations of this problem, in the sense that some additional information is provided that might or might not help to solve the pathfinding problem. One advantage of isogyny-based cryptography, besides being based on really beautiful maths, is that the key sizes are much smaller compared to cryptosystems of other post-quantum candidates. The most prominent key exchange in isogyny-based cryptography is the super singular isogyny-defi-harman scheme, which was introduced by Jao and Tefeo in 2011. It proceeds as follows, let N1 and N2 be smooth copram integers, usually they are chosen to be a power of 2 and a power of 3 respectively, and let P be a prime of the form N1 times N2 minus 1. Furthermore, you fix a curve E0 defined over Fp squared. And two bases of E0, namely of the N1 and the N2 torsion. Alice then picks an order N1 subgroup of E0 as her secret isogyny by choosing its generator, and similarly Bob chooses an order N2 subgroup of E0. Both compute the isogyny corresponding to their secret subgroup and send each other the curve they arrive at, say EA and EB. And further, Alice sends the image of the N2 torsion bases to Bob, and Bob sends the images of the N1 torsion bases to Alice. Using this torsion point information, both Alice and Bob can translate their secret isogyny onto the curve EB and EA respectively, which after one more isogyny computation allows them both to compute the curve EAB up to isomorphism. Essentially, this works because we're quotienting out two subgroups that only trivially intersect, and in the order we do this in does not matter. Since both Alice and Bob arrive at an isomorphic curve, the J-invariant is used as a shared secret. It is easy to see that recovering the isogyny, say phi A, would allow to attack the key exchange. Given E0 and EA, this would be an instance of the pure isogyny problem. However, we are also given additional torsion point information. In our work, we were looking whether this additional torsion point information makes it possible to reduce the problem of pathfinding, or equivalently of recovering an isogyny in this diagram, to an instance of the abelian hidden shift problem. The hidden shift problem is the following. F0 and F1 are functions from the same group G to some programming X. Such that there exists some group element S in G that F0 evaluated at any group element equals F1 evaluated at that same group element times S, in multiplicative mutation at least. The problem is to find the shift S given or actually access to both functions F0 and F1. If G is abelian and F0 and F1 are injective, this can be solved in quantum sub-exponential time with respect to the size of the group G using a quantum computer. This is some result due to Huberberg. Let's look how something like this might look roughly for SIDH. From now on, let's assume we want to recover the secret isogyny of Alice, which is of degree n1, say a power of 2. Then the two isogyny graphs starting at E0 looks like this. While we don't know Alice's secret isogyny, we do know its degree. So we do not know the path, but that EA lies at a certain distance from E0. Assume we have a group action that acts transitively on the possible kernel subgroups defining paths to curves at distance n1 from E0. That is all the curves on the outer circle here. And let's assume that it's efficiently computable given a curve and the torsion point information that one has in SIDH. Then if you take any other path of correct length from a starting curve to a curve, say EA prime, then by transitivity of the group action, there exists one element in the acting group that maps EA prime to EA. The idea behind our paper is that this element is a shift and can be recovered using a hidden shift algorithm if some further conditions are satisfied. Knowing this shift, we can apply it to the kernel of the isogyny from E0 to EA prime that we know because we picked it. And this will give us the kernel of the isogyny from E0 to EA, so the secret of Alice. Let's make this idea more general and let's consider what we actually need to compute a pre-image of an injective one-way function via a reduction to the injective abelian hidden shift problem. Let f from some domain i to a codomin O be an injective one-way function and let g be a group acting on the domain. We call a malleability oracle for g at an image point of f, say f of i, an oracle that provides f of g times i for any element g in the acting group g. Or put differently, the malleability oracle evaluates the function that on an input g of the group evaluates f of g times i. In some sense, this is a group action oracle, but it might be possible that more generally there are schemes where one could redefine a malleability oracle as some knowledge relating certain inputs and outputs. Now, the idea behind finding a pre-image of f of i via a reduction to the hidden shift computation is fairly straightforward if we make a couple more assumptions on the acting group g. Let the group g act transitively on the domain of the injective one-way function i and assume we have a malleability oracle for g at f of i, where i is the pre-image we want to compute. Then if we pick any j in that domain, we know by transitivity that there exists an element sigma such that i equals sigma times j. Define two functions f0 and f1 that map the group elements of g to the outputs of the one-way function evaluated at that group element times j and group element times i respectively. G times j can be evaluated using the knowledge of j and the knowledge of how to evaluate the one-way function in the easy direction. And f of j times i can be computed using the malleability oracle. These two functions are hidden shifts of one another and using a hidden shift algorithm, this shift can be computed in quantum sub-exponential time, at least if we further assume that f is injective and g is a finely generated appealing group acting freely on the domain i. This is to ensure that the solution is unique and that it can be computed with a sub-exponential quantum algorithm. Having computed sigma, like the shift of both functions, we can then compute i simply by computing the action of sigma on j. Let's get back to SIDH. For a fixed starting curve in SIDH, this is typically the curve with j and variant 1728 or one of the close neighbors, and let n1 and n2 be security parameters of Alice and Bob as before. Then the one-way function underlying Alice's secret isogeny is the map sending n1 or the subgroups of a E0 to a curve at distance n1 from E0 and the image of the basis of the n2 function. Note that this function can be efficiently evaluated using the loose formula, but computing free images is the hard problem underlying SIDH. In our work, we show that we can give a malleability oracle for this one-way function under certain conditions. More precisely, let g be a multiplicative subgroup of the endomorphism ring of E0, modulo and 1, where each equivalence class contains an endomorphism of degree co-prime to the degree of Alice's secret isogeny phi. Then a malleability oracle for this group G at EA, which is the starting curve E0 divided out by Alice's secret k, should provide the curve E0 divided out by theta of k, where theta is the endomorphism. By the co-primality of the degrees of theta and phi, we have the following commutative diagram and you can see that E0 divided out by theta of the kernel of phi is isomorphic to EA divided out by phi of the kernel of theta. Since we do not know the kernel of phi, we cannot compute the action of theta on it. However, the idea in our paper is to lift the endomorphism theta to an endomorphism theta prime that has the same action on the domain i of our one-way function, but is of degree n2 or dividing n2. For such a theta prime for which we know the kernel and for which we know that it's kernelized in the n2 torsion of E0, we can then evaluate phi of the kernel of theta prime. This is because the torsion information in SIDH of the n2 torsion points allows to compute the images of all points of order n2. In particular, if the kernel of the theta prime is in the n2 torsion, we can evaluate phi on it. But then given EA and phi of the kernel of theta prime allows to evaluate the bottom right corner of the commutative diagram, which is the same as evaluating the malleability oracle. Apart from this malleability oracle for SIDH, to use the general reduction to the hidden shift problem outlined earlier, there's some more tasks that had to be solved. First, we had to partition the domain of the one-way function, so the kernel subgroups of Alice, well that could, Alice could potentially pig, into large partitions such that SIDH one-way function, that the SIDH one-way function is injective on each of those partitions. We did this by explicitly writing down three partitions. For each partition, we then find an abelian subgroup of the endomorphism ring containing endomorphisms of degree co-prime2 and 1 that act freely and transitively on each partition. And finally, we give an algorithm to lift elements from these acting groups, SIDH, to endomorphisms of norm n2. This is in order for us to have a malleability oracle as described on the previous slide. While we give such solutions for the first two tasks in general, the lifting algorithm we provide works only if we allow SIDH parameters where n2, so Bob security parameter, is larger than p and significantly larger than n1. This is what we call overstretched and unbalanced. More precisely, we choose the group acting on Alice's secret key space such that each element can be represented as an endomorphism of the form Frobenius endomorphism times zi, where i is the non-trivial automorphism of v0. The task therefore reduces to lifting endomorphisms of this form to norm n2. We solve this by solving a norm equation similar to the one at the core of the KLPT algorithm, where KLPT stands for coal outer Pt and t0. Unfortunately, this algorithm works only for n2 greater p times n1 to the fourth and under some heuristics also for n2 greater than pn1 to the n1 cubed. However, the way we solve the lifting, we would not expect solutions if n2 is less or equal pn1 squared. This is also the reason why the attack does not in its current form apply to balanced SIDH parameters or cycle. With some more formal background, let's take one more look at the two isogenic graph containing Alice's blue secret path. In our paper, we put the end nodes of the different paths into three different partitions. On each partition, we have an abelian free and transitive group action of endomorphisms modulo n1. Now, by picking any path that lies in the same partition as Alice's secret, we get to the curve EA prime, which can be mapped by the group action to EA. This follows by transitivity and basically by having three partitions, there are three choices for such a J. We define two functions, one that sends elements of the acting group of the curve you get when applying the group action on the isogenous leading to EA prime. The other one when applying the group action to the isogene leading to EA. The first function we can evaluate because we know the pink path and we can just compute the endomorphism on its kernel. This gives us another isogene of the same length that we can then just evaluate. The second function, the one that computes the group action on EA, we can evaluate using the malleability oracle. Essentially, given an endomorphism of E0, we find another endomorphism of E0 that has the same action on the n1 torsion, but is of degree n2. We use the torsion point information provided by Alice on EA and compute the curve at distance n1 from E0 that one would get when applying this endomorphism to the kernel of the secret, essentially. Both of the functions we define are injective, they are shifts of one another and the acting group is abelian. Using a hidden shift algorithm like Kuperbecks, we then find the shift corresponding to the red arrow in the picture and this allows to compute the kernel of the secret blue isogene from the known pink isogene. Let me summarize the key contributions of the paper. It provides a new attack vector and SIDH-like protocols via a reduction to the abelian hidden shift problem, but the attack only works for unbalanced and overstretched SIDH parameters. Yet the results show that despite SIDH's non-commutative nature, there's an abelian group action on its key space that can be used for this kind of attack. As opposed to previous hand-wave arguments by such an attack should not exist, we give some bounds for when we expect the attack to actually work. We describe which algebraic properties are necessary for the attack in general terms and this captures some previous attacks such as the one of Charles, Jao and Tsukharov and we hope that the general framework might be of interest for future cryptanalysis in other areas. The isogene-based submission to NIST, Psyche and balanced SIDH parameters are not threatened by this attack. Indeed, parameters for which this new attack applies were already known to be insecure by the results of the KEN and others that was published this year at Crypto. If you have any questions, please ask in the Europe Prep Q&A or send us an email. Thanks!


I was born into a Christian family but going to church was a chore for me but recently I started noticing the changes in my life and what church has done to me. I've given my life to Jesus but today I'm going to show my true dedication by getting baptized. Alex do you believe in Jesus Christ as God's Son and your personal Lord and Savior? I do. Do you promise to follow Him with good and clear conscience for the rest of your life? Yes.