Blockchain Innovators - Conor Svensson and Peter Broadhurst

Hi, it's Conor Svensson here, founder and CEO of Web3 Labs. This is a conversation I had with Peter  Broadhurst. Peter is the co-founder and head of engineering at Kaleido. Kaleido is a full stack  enterprise Blockchain as a Service platform. Previously, Peter worked for IBM for 18 years  where he worked on cloud computing and middleware technologies. In our conversation,  we discussed the problems that blockchain solves that middleware couldn't and where he sees the  big opportunities for blockchain in enterprise. We also cover the newly launched FireFly project  which Peter is very involved in. FireFly provides a multi-party system for enterprise data flows  which lets developers build decentralized enterprise grade applications on blockchain  based business networks. Like myself, Peter is a technologist at heart and it was fun to geek out  on how blockchain fits into the broader technology landscape. Peter, great to have you here. Hi  Conor, great to be here. So, you've been involved in blockchain as one of the co-founders at Kaleido  for a number of years but prior to that you were at IBM for 18 years, if I have that right?  And from what I understand, you were working on cloud computing and middleware,  so I'd love to hear about really what you did at IBM and how that ultimately  transitioned into blockchain technology. Yes, I guess it's interesting for me because when  you look at the technologies that I was working on throughout my career, there's a  huge overlap with what blockchain is trying to achieve particularly in the enterprise space.  I started at the beginning of my career working on a technology called MQ/ MQSeries it was, in IBM.  It was one of the original sort of game-changing technologies for how different companies could  do cross-organization transaction processing and it was just a messaging system fundamentally but  it was reliable so you could send something and know it was going to get there.  It sparked a huge, huge wave of these technologies that were about a different  way to communicate. We've all heard of AMQP and RabbitMQ and these other technologies as well.  So that's why I started and it's amazing how similar that is to sort of where I'm back to  now in the blockchain space trying to solve a similar problem. As I went through my career,  I got very involved in the application service stack and the transaction processing there,  the websphere stack and also on the integration side. How  the core systems of enterprise could integrate together and I did a lot of my my time actually in  the support side, working on other people's code rather than actually new development. So I  got to see the whole stack inside and out, which was a really nice journey to be on. And a lot of  work with customers in the last few years at IBM actually traveling, working with customers  sticky projects, complicated things that need to be designed, actually being out there seeing the  kinds of business problems that people are trying to solve with these integration technologies  between organizations. So you say about the similarities with blockchain and  there's been that argument historically with middleware technologies - how they can be used in  an enterprise and they could potentially span multiple business units but there's a point where  it makes sense for a large organization to be working with middleware technologies. Then there's  a point where potentially they could actually want to look at blockchain even for actually connecting  multiple subsidiaries of a single organization without thinking about the external connectivity.  Is there a point there where you feel the natural jump becomes the blockchain? Yeah, absolutely. Blockchain does something that was impossible,  throughout my career, was absolutely impossible. Every previous generation of  how organizations work together before the, we tend to refer to it now as a multi-party  system, there's this new thing enabled by by blockchain tech. Every previous generation was  'I have my source of truth. You have your source of truth. And we're doing some kind of ping pong  exchange. Whether it's SOAP web services or REST or messaging, we aren't agreed on a source  of truth. We're exchanging information from two different sources of truth.' And suddenly  with blockchain, if you build a multi-party system that's got a blockchain in the middle  there, it's game changing because you can have a shared source of truth with other organizations  and you don't have to trust them to trust the source of truth. That means that a network of  businesses which are cooperating and competing, this sort of competition can work together  and have certain agreed truths such as sequences of events or in tokens, total conservation of  value or uniqueness of one particular reference ID in the world that we're all using for the  same thing. Those base constructs completely change the kinds of problems that you can solve  and get away from, we used to call it compensation logic, it's so complicated. Like, 'I said this  to you, you said that to me, it all happened at the same time, we end up with different results,  how do we sort out the mess?' And sorting out that mess with people involved in business processes  could have taken weeks in the past in real world scenarios. And with the multiparty system,  if you can get it right and you can get the balance, the right things to be the shared data  and you still get the privacy side of it right, then you can take those sort of weeks and just  have agreements immediately. Agreements that no one would bother to challenge because there's an  audit record that's just so clear. But, you don't have the sort of 'Where's my message problem' of  'Did I say that first?' 'Did you say that first?' 'I think I said it, but you didn't  confirm that.' 'Does that mean you didn't?' All of that goes away with blockchain which is fantastic.  Is this something that you recognized when you were still working at IBM or is it more something  that you've developed a real narrative around as you've spoken more and more with customers  working with blockchain technology? That's a great question. Blockchain was the exciting  new thing that was happening in enterprise for a few years while I was still at IBM.  So it would be the water cooler conversation, right? It would be with the person who's just  gone to the blockchain team to build blockchain stuff because it's fun and new and interesting.  So I think that excitement was certainly there for me, that the possibility it just seemed to me like  this was the first technology that could change the core of businesses rather than the outside.  It could actually change the way business core transactions happen. It wasn't just  about surrounding and connecting stuff. It was actually about changing the core way an end-to-end  business transaction happens and that means for enterprise IT, it's huge! The potential, still  nascent honestly, potential for cross-industry revolution on how business gets done. I think  it's a unique technology from that perspective. So yeah, that was why it was so exciting to  launch into Kaleido, out of that because it just felt like this could really change things in a  meaningful way. And really make things better as well because, another side of blockchain is that  it increases the transparency. It can increase the trust that users of systems can have in the  systems themselves but organizations start to work together in new and interesting ways which  are more open, more collaborative. They're building business ecosystems rather than  completely centering in one business and that's really exciting for lots of different reasons.  Not just what it can do for the big enterprises themselves but actually what it can do for us all  in terms of systems working better for people. That's something I think about it in terms of  businesses almost turn themselves inside out when they're engaging, making use of the DLT because  although there is of course privacy considerations,  you're not making available sensitive information, but it's like how the processes can actually run  in that sort of collaborative environment there. Do you think about there being parallels though  with projects like the Baseline Protocol for instance? They talk about this notion of  blockchain can almost be used like a middleware technology between these different organizations.  The fact that you've got this kind of layer of programmability that can happen at the protocol  layer is one of the distinguishing features with blockchain, but do you think there are  parallels in that regard as well? Well, yes. I guess we've been on the journey throughout  Kaleido the last few years, seeing how real projects get to production on blockchain. The  cold hard reality is, it is a lot like middleware because these organizations aren't immediately  going to be throwing away all of the core systems that exist inside of those businesses. So the  only way that a blockchain ecosystem can be valued to a business is if it integrates with the core  systems that they use on a day-to-day basis. It's got to make their business better  in a meaningful way and if it doesn't integrate then it's a real problem. What we've actually seen  is that there's two things that matter, matter hugely when you're going about one of these  projects. The first is getting the use case right so that you can demonstrate real value that is  valuable to the players in the system. The second is being able to take the skills that exist across  those organizations, rather than just the skill that exists in some central specialist team  that understands blockchain protocols and zero knowledge proofs and baseline and all of these  low-level technologies, you need to be able to engage the actual integration teams,  the data engineers, the application builders, and you need to be able to... and this is the really  key point... get to a proof of value quickly because I think the fact that it is a lot like  middleware, it doesn't do anything on its own. The thing about middleware that's been true throughout  my career, you're working on the plumbing, the bit that doesn't deliver any value in its own right.  It's hugely valuable, but on its own it doesn't generate the value. It's a tool that allows  use cases to be built on top of it. So, what's the most important thing about a piece of middleware?  How quickly it enables developers, and for blockchain ecosystems and developers, to build  solutions. That's the most important value that it has. How sophisticated and clever it is inside,  is really useful and the subtle differences between the blockchain technologies, the  different ways that you can use them, that's great. But really  what do business ecosystems need? They need proven patterns that have worked elsewhere  just made available to them sort of as middleware, so they can build applications on top. We've been  astonished looking over the last few years and coming to projects that have been going a while  and that we've been helping with and building projects from scratch, just how much rebuild of  the plumbing is kind of the norm in projects. We try desperately to avoid it, right?  That's just not where the value is coming out of. So, you need to build on top of it. But we've seen  incredible amounts of resource being used on just building the plumbing necessary  to have a blockchain network with everyone having the nodes,  have the transaction streaming on, have the events coming off, have the private data  integrated with the blockchain data, all of that stuff that isn't about how do I actually build an  application on top of it. Just taking ridiculous amounts - years - project years of time.  I think that more than anything, that's the thing that will allow the next wave of innovation,  of production innovation, on blockchain is going to be projects just being able to  iterate the use case level rather than the plumbing level. Yeah. Certainly with what you say,  it makes you think of a couple of things. Firstly, with the number of hackathons that have happened  where the output of the hackathon is getting a blockchain up and running  back in the earlier days and also with enterprise architecture specifically, it's not had it's sort  of enterprise integration patterns moment where you've got really well-defined approaches for  integrating these different types of solutions for this. One of the things though that you spoke  about there as well, was the actual use cases and the importance of having the right use case too.  What are the things that come to mind about one of the really good use cases here? It could be  that you give specific examples or it could be just more than calling out the properties that  you feel very relevant. So I probably will give just more general answers. But, one of the things  and one of the journeys that led us to FireFly, that it'd be great to talk about a little bit,  where we're trying to take those patterns and make them in an open source way rather than it  just being - you come to a company like Kaleido where every developer should be able to develop  these use cases. What we've seen, maybe uniquely in our journey in Kaleido or maybe not, is that  we've seen lots of patterns that across industry beyond the core financial token ones. Just a few  examples, one is around improving business processes, multi-party business processes. Cases where it takes UPS trucks and planes flying around the world and physical documents exchanging  to allow ships to leave ports or money to actually close out the end of some business transaction.  Those kinds of use cases, the efficiency gains can be huge. So  improving the way an end-to-end business transaction works is one really critical  one. Another one we've seen which is really interesting and we've seen  across industry over and over again is enterprises at their core are about the data that they have  in terms of the IT landscape. When you're trying to do something in a business ecosystem  of any kind, everybody's got that own source of truth and their own internal amount of data.  Data on customers, data on transactions, data on products, data on things  and one of the biggest sticking points is that everybody is constantly spending time and effort  trying to make their data consistent and correct and make their data consistent and correct for  everyone else in the business ecosystem. They do that because there's no way for them to share data  and this is as true as it is for health care data, as it is for insurance data, as it is for  core sensitive cross-government department data. They have strong regulations that mean  they have been really careful about how they share data with each other  but they actually want to share the data with each other in certain scenarios because they  also have requirements that mean they must be able to agree on certain core things.  I'll give a specific example that might sort of bring it home which is one you can read about from  a really fantastic organization, called Wish Stream, which is part of the institute's, one of  the biggest groups of insurance organizations in the US. They have a use case around  what they call mortality monitor and this problem that all of the insurance companies need to  pay out to people in the case of a bereavement. And the poor people who are dealing with that,  which is incredibly hard for the the actual people who are dealing with bereavement,  are asked to provide data, the same data, tens of times during the process because those  individual insurance companies actually being able to share that information is really tough.  That delays payout of the actual insurance to the bereaved and it just causes a huge  amount of human suffering, right? In terms of having to go through that  to actually prove that somebody has passed away. That problem amazingly  can be solved using blockchain at the core in a way that it couldn't have been solved  before. So there were use cases that are just like a world away from here's an SDO issuance or  I've got an NFT of a fantastic football player that I want to put out there on the web. There's  use cases that are just hugely detached from them. But the core constructs of uniqueness, things like  tokenization to help the ecosystem work, can just transform the way it happens. Yeah, absolutely.  So I know that you obviously want to talk about FireFly as well. This is a recently publicly  announced project within Hyperledger. It's come out of the work that you've been doing over the  number of years now at Kaleido and so for those of people who are listening who aren't familiar  with Kaleido, it's probably worth just introducing a bit more about who Kaleido are and what they do.  Then, I think talking about about FireFly and why it's so exciting, why it's so relevant right now.  Yeah, that's great Connor, thanks. Kaleido's a startup that's focused exclusively on this problem  of money party system. So we're a specialist in the blockchain space and we focus on making this  technology consumable for enterprise. So back at the beginning, we started with some of the  problems, which as you pointed out back then, people were spending huge amounts of time on  'how do we get a network up and running?', 'how do we get the right balance of decentralization  and sovereignty and consistency to actually have everyone's got a blockchain node?' Right? 'What  does that look like?' 'What's the right balance of hosted and hybrid etc. approaches to having  a blockchain network up?' That's where we started. We launched on stage. Our Public  as a Service offering with AWS there were up on stage as we were the first managed service  that they had and continued to go on to partner with Microsoft as well and Provide's as a service  infrastructure. But immediately, as soon as we'd done that, we actually started then building on  top of that and building some of the services that were new, that didn't exist. One of the  earlier services was how do you get transactions streaming onto a blockchain. How do you get events  coming off, and then things like organization to organization private encrypted data exchange  output messaging large documents, building that sort of stack on top and providing as a service  a sort of solution stack for building enterprise applications. We work directly with with network  operators and enterprise business networks and we help all the way from the developments of  the application use cases, the decentralized app, and the end user experience and APIs,  all the way through to providing that enterprise grade as a service infrastructure in the back end  that allows this network to have their software infrastructure connected back  to their organization. It also allows everyone to go fast enough that they can connect together  and that's why we we also do focus a lot on providing as a service infrastructure still. So, with these building blocks that you created, you started to see some common patterns emerging  there, right? And some problems that you really felt that you were solving  that were probably bigger than Kaleido itself? Yeah, for sure. You know, it's a big decision  for an organization like ours, that has a lot of unique insight in the space, to go and say 'well  the thing we were gonna do is we're gonna take the crown jewels and we're going to  make them available', right? That's a really big decision and the reason why we felt it was  just what blockchain needs is we were solving the same problems over and over again. We had the  tools on the truck to do it but when you look at the blockchain sort of revolution and where it is  and you know as it's encompassing more technologies, it's still not achieving  the scale that it should be. It's not there yet. It's too hard to build a blockchain solution.  It's that the patterns just aren't readily available and we drew a number of parallels to  a technology I love and saw evolve during my career of Docker. Back at the beginning of Docker,  there were people in the space that were like 'this is gonna change the world',  like 'this is amazing, the way you can put any software in a box and make it consistent,  this is just gonna change the way everything runs', 'it's going to change HA models'. But  Docker on its own was brilliant on your laptop, but it didn't actually solve the problem  and people like me, building cloud solutions, were like 'well we need a whole layer on top'.  I built three generations of cloud services before I came to start Kaleido. The first one we built  the whole orchestration layer ourselves. We built it, we used the Hashicorp console at the time  and Zookeeper directly and we built it all, right? We've got the whole orchestration layer.  And then the second generation it was like there were lots of orchestration layers you could  pick between, Marathon and the like. Then Kubernetes came along and the game  changed. No projects had to think about any of this stuff, there was just this brilliant API  programming model and set of objects and you just used it and the patterns were there.  That piece of the project of 'how do I build the cloud infrastructure?' went away. And we know  that's what the blockchain industry needs. What innovators of decentralized multi-party systems  need is the technology to become consumable for them, not just consumable for this specialist  inside of the blockchain space, consumable for them and FireFly is our attempt to see that.  To try and start a community that's focused squarely on making the orchestration layer  that makes all of these technologies fit together and it embraces the fact  that the block changed just one component. We see like 20 to 50 components in this, inside of these  projects. Lots of them are application components, lots of them were off chain. You've got to fit the stuff together and that's what we're trying to do with FireFly, is make  it easy for the people who have to worry about everything, not just the people who are worried  about the blockchain piece itself. So, let's break it down for people in terms of what it comes in  and exactly how it works. So, I'm a business. I've realized 'hey I could put this blockchain in  to simplify this process that we currently have that's spanning multiple intermediaries within  our organization' and 'so great we've got this blockchain, we've got some smart contracts or  decentralized apps, whatever flavor running on top of it, but that's obviously not enough'. So how  does FireFly come into that and what additional value-add does it have if you start with this  blockchain application focusing on a business problem that it's solving? So, first thing is this concept of a multi-party system. That's what you're trying to build.  Think about what you're trying to build is different to if you're building it  on a database, centralized. What makes it different? The thing that makes it different is  everybody's going to be running their own copy of the application. That's what makes it different.  So, if everybody's going to be running their own copy of the application, the application  is going to be integrated with a security system. It's going to be nice and have a beautiful user  experience, mobile web etc., and it's going to be responsive. You're going to have a whole stack,  a whole stack of tech that each individual organization needs to run, customize and integrate  to their stuff. So what's that stack going to be? That's where FireFly fits. FireFly comes and says  'here's a starting point for that stack that you can build on top of', 'here's a starting point  that integrates with a whole range of back-end technologies'. So behind the FireFly API, which is  REST designed for developers who work in modern languages, full stack developers who live in React  and typescript back ends, right? Or, enterprise developers who are used to  Rest APIs and building Spring boot microservices, right? Here's a stack that you can build on top of  and you can plug in behind so choose your blockchain ecosystem, find the one that's  got the best enterprise tech for you, it can be Ethereum, Fabric, it can be Corda,  those are the top three at the moment. So, that's where the focus is for FireFly.  Choose how you're going to connect together the pipes between the organizations, right? They're  going to need private exchange as well, choose the right tech for that. Maybe, we hope, come to  an organization like Kaleido that's got all of those pipes pre-built or FireFly's got those  pipes built in as well and the plug points to add additional pipes. So whether that's direct HDP to  HDP, mutual TLS or messaging technologies with the reliability and the end-to-end  encryption and just take those off the shelf and have a set of lego grips that let you do the  blockchain pieces, the money party communication pieces, and then build your app on on top.  The HA model should fit into the way that you build your application, the database model should  fit into the way that you build your application. This component should just fit with the way you  would have built the application before. You don't have to build your application differently  apart from you just have to need to think about the fact your application is going to be running  multiple copies and everyone's going to have their own copy of it. So, sometimes you need to  figure out what state is shared, which usually most of it's going to be privately shared,  that's just the reality, right? What data is completely shared? Open to everybody. And then how  is the communication going to happen? And how is that communication going to be different? Because,  you can share these pieces of information, the sequence of events, what's going to make it  different? That's kind of the recipe but FireFly's there to try and make it 10 to 100 times easier  than we've seen it be in the past. That's the goal of FireFly. Then I guess, to complement that as  well you've got the usual widgets, like a nice UI for monitoring it and these sorts of pieces too?  Yeah, so the intention here is this isn't a dump of the piece of bits that we've had. We've done a  huge amount of engineering since the design of FireFly. It's actually a new generation of the  core technology. We rebuilt it in Go, we built the explorer, the FireFly explorer, from scratch on  top of it to give that live modern experience that people expect from a great technology. Because  that's what we know all the open source projects that we love, do. So we want this community  to be the place where that kind of innovation can happen. We've seated it with lots of components,  not just the sort of core plumbing pieces but with the command line so you can have it running  in 30 seconds on your laptop. You can have a full stack with three members simulated and be working  with the Rest APIs. You've got full open API, free Swagger, for all of the stuff just there. But,  that's as important for this project as how fast and clever the internals are, which of course,  is also a big focus. When you're dealing with privacy, you have to think about what are you  linking and there is a lot of plumbing inside of there that's about coordination of events,  on chain and off chain, because that's a really hard problem that the individual components  can't solve. And a lot that focuses on what's the right model for privacy in these organizations. So  there's heavy lifting code in there as well as the orchestration pieces. And so the project's just  been donated to Hyperledger from the governance perspective. At the moment it's in this sort of  incubation stage because it's a new project there and then as traction grows around it, it'll move  out of that. There should be people listening to this as well who are technically inclined and  interested to find out about getting involved in the project. What are kind of the things you want  people to do with it, apart from try it out to see if there's the potential to use it in their  current projects. What would be your ideal ask for people who come across the project beyond  that? So, that ask is really strong, trying to use it, seeing if it does make the problem  you're trying to solve easier. If it helps you understand the problem that you're trying to solve  as well I think, that's really important. We want that engagement. Come along to the community  course. They're weekly at the moment, they'll fall back to bi-weekly once we've got through  lots of architecture, playbacks on what's there at the moment. But, at the moment, those are weekly  so you can come along. We try and make sure only the first half is a deep dive presentation and the  second half is just completely open to discuss, to bring your ideas. So, come with your ideas,  come with your skepticism as well and let's talk it through. And then, because it's about pluggable  components, there's lots of opportunity beyond just working on the core FireFly  to work on plugging in technologies. So the fact that it's multi-protocol means  the Ethereum leg is very mature, the Fabric leg is actually really in the innovation stage at the  moment and Jim Zhang another one of my co-founders here, he's worked on Fabric since the beginning,  is helping coordinate the efforts in that space. So that's nascent and there's lots of opportunity  to get stuck in. There's lots of enterprise innovation there, so you can get really stuck  in on the engineering side there and the Corda one as well. We've actually had some previous proofs  with real projects. There's some more innovation needed to make it fit the whole model because  Corda is slightly different as a technology to the other blockchains. So that's a whole area of  plugging in technologies. But there's also other technologies that can plug in the arm blockchain,  like we've got IPFS and we've got private data exchange over mutual TLS but you know plug in  your own messaging, plug in the messaging technology and adding building blocks. Then,  one other thread which is going on at the moment which is really active and we think there's lots  of innovation for is tokens. In terms of building blocks, the sort of air and water we're building  an application. Tokens and how those sort of core operations of tokens, which I feel are like CRUD  for databases, tokens are for blockchain. Those corporations, how those fit with the orchestration  needs to happen off-chain. That's something that's really happening actively on the project.  So there's loads of places that you almost certainly have skills that would fit in to the  model that we're trying to enable with FireFly. It's not just about blockchain skills is a really,  really important thing so the community is one where probably everyone who's an  engineer has something they can bring to the community, the community would benefit from. I guess the other thing just to highlight as well is that there's no fee or anything to take  part in it, it's completely open to all of the actual community there. You don't need to be a  Hyperledger member or anything like that to engage with it and contribute to the project. Absolutely,  it's all Apache 2, open source so it's genuinely open community. Everything that we do is in there,  is in the public and the best place to get started is you can come to Kaleido, click open source and  go to the FireFly section to learn a little bit about the background and our seeding of it. Then  just go directly to the hyperledger/firefly git repo  and you'll get to all of the open documentation,  the actual source code. Repositories there's actually a bunch of them because it's a sort of an  umbrella project with components underneath it and the plug-in interface. They all start from  hyperledger/firefly on github and that's where all of the open collaboration happens. So apart from  FireFly and just governing and growing and just making making it better and better, are  you focusing on anything else right now? Are there some other things that Kaleido as an organization  are working on that you wanted to highlight or future directions? Yeah, it really is just one of  the things that we're doing over here, I guess a lot of our focus as an organization is on helping  these unsung heroes of the blockchain space, the network operators, the organizations that form  either by donations of lots of large enterprises into a group of people or actually as a separate  organization. We are working with, a lot of our time is actually spent just working with those  network operators, with the business networks themselves, to accelerate them to build use cases.  And for that reason, we've done a lot of innovation around the model, the technical model,  for how a network manages infrastructure. It's really interesting because it's  not just the blockchain components, we talked about there's the application components as well,  so one of the biggest things that we've actually been working on over the last  year, is that evolved model for how a network manages building an application together,  all the way from building and then hosting all the components. So that's from the technical side,  that's a big focus for us, which is around hosting management network operations  beyond just the blockchain itself. And obviously helping organizations, groups of organizations,  usually with a network operator but not always, to actually deliver value. That's the other piece. So  a lot of our time is actually spent building applications and helping accelerate projects.  Awesome! So just just before we wrap up, I know you've spoken about how people can follow  what's happening with FireFly, if anyone wants to reach out to you or what are the best places  to find you? Is it Twitter, LinkedIn, by the community calls? What would you encourage?  So, a couple of ways... if it's about FireFly, then Rocket.Chat is the way to go,  chat.hyperledger.org, you can get us individually, you can get me directly on there. There's a  FireFly channel that you can go and engage with the community there. So Rocket.Chat is great. For  me personally, LinkedIn is probably a great way to get hold of me and I love to have DMs on there. Or  reach out to me at peter.broadhurst@kaleido.io directly if you want to email me. Well, thank you Peter, it's been really great to catch up  and also learn about FireFly as well. It sounds like it's something that's been missing from the  ecosystem and so it's a big step forward in terms of enterprise and blockchain.  Thanks so much Conor for inviting me. It's always always great to catch up. I know we've  been working together for a number of years now and what you and Web3 Labs do for the community  as a whole is is fantastic. So thanks for having initiatives like this and ways for people to share  and engage together on these interesting topics. Thanks Peter, I appreciate it, cheers. you