Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Rob Dawson: PegaSys – Enterprise-Grade Ethereum Protocol Engineering

Episode Date: July 4, 2019

We're joined by Rob Dawson, Head of Product at PegaSys. PegaSys is the protocol engineering spoke of ConsenSys, and the team building Pantheon, a Java implementation of the Ethereum client. The Pantheon client was built from the ground up as both a mainnet, and consortium chain client. Written in Java with an Apache 2.0 license, it benefits from being easily accessible to enterprises, who predominantly use that language. The PegaSys team has built additional features into the Pantheon client like privacy, permissioning, and the ability to deploy chains on IBFT, a consensus algorithm better suited for consortium networks of up to 40 validators. Working closely with other protocol teams (Geth and Parity), and being a founding member of the Ethereum Enterprise Alliance, PegaSys is also working towards Ethereum 2.0. Topics covered in this episode: Rob’s background as an enterprise Java developer and how he became involved in the blockchain space The role of PegaSys in the broader ConsenSys ecosystem The Pantheon client and why they chose to build a new Ethereum client The case for Java and why enterprise has a preference for this language Pantheon’s unique features of privacy, permissioning, and performance What is Istanbul BFT and how it differs from Parity POA and Tendermint BFT The types of applications which are better suited for IBFT The Ethereum Enterprise Alliance (EEA) and PegaSys’ work on standards PegaSys’ work on Ethereum 1.x and Ethereum 2.0 The team's recently announced certification program Episode links: PegaSys Website Introducing Pantheon, a Mainnet Java Client - Demo & Roadmap (Devcon4) Another day, another consensus algorithm. Why IBFT 2.0? Scaling Consensus for Enterprise: Explaining the IBFT Algorithm Blog Posts and Webinars - Pantheon PegaSysEng/pantheon: An enterprise-grade Java-based, Apache 2.0 licensed Ethereum client PegaSysEng/artemis: Java Implementation of the Ethereum 2.0 Beacon Chain Komgo Sponsors: Trail of Bits: Trust the team at the forefront of blockchain security research - https://trailofbits.com Azure: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks - http://aka.ms/epicenter This episode is hosted by Sebastien Couture. Show notes and listening options: epicenter.tv/294

This is Epicenter, Episode 294 with guest Rob Dawson. This episode of Epicenter is brought to you by Trail of Bits. Don't leave your project's security audit to just any firm. Trust a team with decades of experience at the forefront of blockchain security research. Go to trailofbits.com to learn more. And by Microsoft Azure. Do you have an idea for a blockchain app but are worried about the time and costs it will take to develop? The new Azure blockchain dev kit is a free download that brings together the tools you need to get your first app running in less than 30 minutes.

Learn more at a.kia.m.m.S. slash epicenter. Hi, welcome to Epicenter. My name is Sibbisankwitu, and today my guest is Rob Dawson. Rob is the product lead at Pegasus, and Pegasus is the protocol engineering spoke at consensus. What they're building is an enterprise-grade Ethereum client called Pantheon. And it's enterprise grade for a couple of reasons. One, it's built on Java, which is the preferred language for many enterprise companies out there. And also, it offers a number of performance improvements over some of the other Ethereum clients, which Enterprise are obviously interested in.

And so Pantheon has built a, has built a number of features that are interesting for consortium networks. So on the permission side, so Pantheon has a whole stack of technologies that allows for consortium networks to build permissions into the network, on privacy as well, for doing shielded transactions, and also on the consensus side by information. implementing IBFT, which is a consensus algorithm that works best in permission networks. And Pantheon is also mainnet compatible. So it works perfectly well on mainnet. In fact, I think there's a couple of Pantheon nodes operating on mainnet. So the idea here is really to

bridge the gap between the permissioned blockchain space, where enterprise are mostly focusing at the moment and slowly bringing those companies closer and closer to onboarding mainnet. So it was fascinating discussion and we got to talk to, I got to talk Rob about the client, but also some of the work that they're doing on the protocol engineering side and the work towards Ethereum 2.0. So with that, here's my interview with Rob Dawson. Hi, so I'm here with Rob Dawson. Rob is head of product. at Pegasus and Pegasus is the protocol engineering group within consensus and their role is to build the protocol and so they're building an Ethereum client within Consensus and an Ethereum client that's actually targeted to enterprise. Hi Rob, thanks for joining me.

Hey, it's a pleasure. So let's start off by looking a bit at your background and how you got involved in this space. Yeah, sure. So I guess I've been building software since last millennium using, be a mix of Java, Ruby JavaScript, building enterprise software, and then also working with startups. I also took a bit of a bit of a time out for a while doing a research masters into information security. And so looking at secure protocols and that kind of stuff and had a, have had a real interest in that sort of security side of things. And crypto, to me, I'm old school enough that crypto doesn't actually mean cryptocurrencies.

Crypto means cryptography and real crypto. And so I guess I've been sort of doing that mix of building software and being interested in information security and crypto for a number of years. And so more recently, had someone that I'd worked with before joined the Good Ship Pegasus in consensus. They reached out to me. That was kind of early in the formation of Pegasus

and talked to me about it. I had not been drinking too deeply from the fire hose of crypto currencies at that point in time. And so really dug deep and, you know, wrapped my head around how Merkel trees were working and all the sort of foundational stuff behind blockchain. And, yeah, got excited for the potential of what the technology can do and joined and have been loving it. So you're saying that cryptocurrencies are not real a crypto? Yeah, you know, they're crypto, but real crypto is cryptography, which is, you know, that's what you should do. You're talking about when you're talking about crypto.

Sure, of course. You know, obviously cryptocurrency use cryptography. I think that's why people call them cryptos. But jokes aside, looking at it from a security perspective, you know, when you came into this space after, I believe you have a background working in enterprise and building enterprise software, what are some of the things that? maybe pleasantly surprised you about how the community was building software and or were there things where you just kind of face-pombed and like what's going on here? How are people what are people working? Yeah, so it's you know the the open source sort of nature of everything was was was really really great to see and I think that's probably the the first part the the fact that

when you look at Ethereum in particular the the core devs the there, which, you know, it's not like a secret society. It's a pretty open core devs network where you can reach out and be a part of this community and be able to contribute so easily is pretty amazing. On the flip side, some of the face palm-y sort of stuff might be, sometimes it feels a little bit like the Wild West still in terms of building robust software. I think there's been projects which their CI sort of being read has been something that, you know, failing CI for me as an enterprise dev and just as a product-focused dev feels like, as soon as you see a bill being read, that's like warning bells, go change it, fix it,

make sure that it's passing its tests, make sure that it's working right. Whereas I've seen clients and software that has been in a sort of red state for months at a time. Okay. So what's CI? Continuous integration. Oh, okay. So some of the things and basic things that you, as a software dev and experienced enterprise dev, you expect there to be there. So making sure that there's a good automated test suite that's making sure that the code does what it's meant to do. If someone changes something and behavior and it's going to break things, you actually get told and find out. So I think elements of that are there, but it's not as, not as robust as would make me really excited.

Okay. Why do you think that that's not there? I mean, if those are sort of like, you know, already established things that people build into their software building process? I think parts of it are the ecosystem being driven by research and being like people that are excited about the possibilities of technology. and so moving quickly from a proof of concept to it's actually being used. And so I think some of it's just the, I guess, the maturity of the ecosystem. Okay, yeah, that makes sense.

How did you get involved at consensus? It was definitely just a, it was a referral. So I knew someone who'd worked, who was working here. They said, come along and took a bit of a look. I really was not looking to change what I was doing, but I'm glad I did. Okay. And so a couple of months ago, we had Joe Lubin on, and this was, I guess, in the middle of this moment where a lot of companies were downsizing and consensus was also downsizing. You know, have you guys felt that within your spoke and sort of broadly in the organization? How do you see the organization changing over the last few months?

Yep. So I guess in terms of our spoke, we were, fortunate, I guess, that we weren't directly impacted. I know, have known a number of people that are no longer at consensus, and it's a shame that they aren't. But I think overall, for consensus, it's been a good move. I think it's sort of allowed to be, I don't know, the corporate, corporate background of me says tightening a belts and all those sorts of glib statements. But it is a little bit of that. And so I think helping to focus on being at almost a bit more of a grown-up company. While still keeping that a lot of the great experiments that Joe's always had there, so the decentralization of the organization still feels that roots very strongly.

Moving now to Pegasus, what's the high-level goal of this spoke? There's a vision and mission which really boils down to the idea of making sure that we remove the friction in having transactions happen. And so the way you're going to do that in Ethereum, and that's being a part of Pegasus, that's being a part of consensus, that's where our natural sort of effort is, is going to be focused around Ethereum, is making sure that you've got a really top-class Ethereum client. And so that's making sure that it's, making sure that it's, available to be used by everyone, giving it an open source license. So we're an Apache two licensed piece of software, so making sure that that's easy for enterprises and anyone

to be able to use, making sure that it's really high quality enterprise grade software. And so it's got that the continuous integration sort of backing it. It's got the tests that are happening to help give us the confidence that the protocol that the client is of the right standard and of the right quality. And then adding in some of the enterprise features that are important for consortiums and for those private kind of networks to be able to use, while also giving them that path to using mainnet, because I think the Ethereum mainnet is the future, be it the current Ethereum mainnet or Ethereum 2.0 mainnet, that's the future. And so I think we see building out the capabilities for our clients and our

software to work well in both that enterprise context and then the main net context as well. Okay. Yeah, we'll get to that as the show progresses. But staying on Pegasus a little bit, what is your role sort of in the broader consensus community? And also in the Ethereum space, what are your interactions with other teams and other client teams and protocol engineering teams out there? Yep. So we, in terms of the consensus context, we work, closely with a bunch of the other spokes to make sure that we're both building the client and then any enterprise features that we're building that they fit in with the rest of the consensus kind of tool chain. And so places, groups like Elethio, in Fuhrer, we work really closely with.

We are working with Collido as well for that sort of enterprise hosted version. We sort of have done work with Truffle to make sure that we work well with Truffle as well. And so it's kind of working and partnering with the rest of the parts of consensus to make sure that we're delivering the best client possible. With the community, there's a few different spots where we really see it sort of flesh out. And so we're a part of the core devs calls. And so we've got, I don't personally get to go to many of them because they're in the middle of the night for me. But we've got one of our guys, Dano, is regularly on the core devs calls, helping to work together. with the other core developers to ensure that we're taking the Ethereum clients forward in a

sort of consolidated fashion. So making sure that we keep the beautiful decentralized parts of Ethereum really strong, while also helping to push forward and ensure that the protocol does grow to be the great protocol it wants to be. And then the last part then on the community is getting involved with the Ethereum research, and we've got a very active team working with the, actually two active teams working with the Ethereum 2.0 sort of research efforts. So one of the teams is very much on the sort of more sort of future theoretical kind of side, and then another team is actually building out some of the early proof of set concept clients

to help make sure that we're actually delivering on Ethereum 2.0, that it doesn't just become a more academic exercise, that it's actually shipping real working software that people are able to use. Would you say that within consensus, there's this push to get the quality of all the different software coming out of all the different spokes at this enterprise grade quality? And is Pegasus pushing that? Is it coming from Pegasus, or is it coming sort of from top-down?

and being brought on to every spoke? It's a good question. I think there are quite a number of spokes that are really, really pushing hard. So it sort of depends on where a spokes are in its life cycle, I guess. So there's a number of spokes that are at that spot where they're getting that product market fit. And I're seeing that their product market is actually very much in that enterprise space. And so for those spokes, actually really focusing on the quality is really important. There's other spokes where being able to innovate really rapidly is the key thing for them at the moment.

And so for them, maybe sometimes there's that trade-off between let's write another test versus let's try out this new idea. They might lean more towards trying out the new idea. And then with regards to your interaction with other teams, and so, for example, like the Geph client team or the, the parity client team, you know, coming from this background of enterprise and also working with enterprise building this client, how have your interaction been with those other teams? Do you see that there's a high level of desire also on their part to build a more robust client, like build tools that are enterprise ready? Or are you seeing that they're more looking at it from the research side and maybe not building

in this continuous integration that you mentioned? And how would you describe the interactions with the other teams on this front? It's been really great working with the Geth and Parity teams. They're a bunch of really smart people. And it's been really amazing being able to see the ideas that they're trying and be able to work alongside them to help work things out. On the main net front, they still very much are the leaders in that space. And we're working our hardest to catch up.

And it's hard because they've actually done a bunch of really interesting things to make sure that they can make their clients go really fast and are tuned for the main net world. And so in a mainnet space where we're working hard and I think we're catching up, but they are really smart people and it's great to work with them. Let's talk about security. You know, DAPs are pretty unique because unlike other types of software, they can hold astronomical amounts of value. That's why getting systems audited, creating robust security processes, and fostering a culture of security in your organization is so important. And to do this, you should only trust experts with real security expertise. There are a lot of security firms in the blockchain space, but few have the experience and track record of Trail of Bits. And they've been in business since 2012,

long before things like the Dow Hack were even imaginable. Trail of Bits works with your team to audit every aspect of your project. And smart contract code is just the beginning. They'll help you implement best practices around things like DevOps, key storage, and user-facing applications. And once your software's been rigorously tested and reviewed by Trail of Bits, they'll provide the tools you need to make sure that your code remains safe over every new commit. They can even put a software security expert at your team's disposal who'll give you advice and answer your questions when you need them. It's like having your own security engineer on staff, but don't take my word for it. Go to their publications repo on GitHub

to read their papers, presentations, and and security reviews. It's no wonder teams like parody, status, Newseifer, and organizations like Facebook and DARPA trust TrillowBits for their security audits. To learn more, go to trailfbits.com, and if you decide to reach out, make sure you let them know you heard about them on Epicenter. We'd like to thank TrilofBits for their support. Let's move on into Pegasus, the main product that's being built by Pantheon. Why did you decide to build another Ethereum client? Why not just use Geth and Parity or maybe branch off of Geth and Parity? What was the desire here? It's really important for Pegasus to build Pantheon because it really gives us control over

the client. We'd looked at some other efforts that have been made to produce more enterprise focused clients that were branching off Geth and Parity and saw. a lot of the pain that ended up happening in having to maintain that fork. Being able to maintain a fork of any open source project is non-trivial. And to be able to add in some of the enterprise features, in particular privacy, requires enough deep changes to the client that maintaining that fork is non-trivial. So that's one of the aspects. The other is being able to offer enterprises a client with an enterprise-friendly license is really important. And so the L-GPL and GPL still raise flags for a lot of enterprises. And so we've got an Apache 2 licensed client, and that really

makes a difference. Can you talk about why this license is problematic for enterprise and why Apache? Because I know that also HyperLedger built everything on Apache for that exact reason. So I'm not an open source guru, so probably not the best person to answer that. You should have a conversation at some time with Jim Jagowski. So he's at consensus as well and was formerly at the Apache Foundation. And so he's got a really clear ways of being able to articulate why Apache 2 matters. Essentially, it comes down to the fears around the viral nature of the G-G-G-C-Rae. sort of license. And so once you have something that's using GPL licensed code, your code then

also needs to be GPL licensed. And so it's organizations being afraid of that. Whether or not those fears are valid and whether or not how that that really plays out, it hasn't been tested in the legal system. And I'm not a lawyer and I don't know how it would pan out. But it's just one of those things where if you do have the choice between, for a lot of organizations, if you have the choice between, and particularly, I guess, for developers in an organization, if you have the choice between something that's Apache 2 and you can just use versus something that's LGPL or GPL and you have to go through the legal team of your organization to get approval to use it, you're going to go to the Apache 2. It's just going to be so much easier. And so given that we wanted to have a client that

was easy for enterprises to pick up with. Having that Apache too was one of the parts of that decision making. Okay, that makes sense. So in the GPL license, these open source licenses, I guess, force users of those software to also open source the things that they built with it. Whereas Apache, you can use this open source software, but it can be closed source within your organization. You don't have to go in open source it yourself.

So it protects, I guess, companies and enterprise and protects their IP and so their business because that software doesn't itself need to be open source. Right. Well put. Okay. So why is it that enterprise predominantly work in Java? So I think it's a lot of it's the historical reasons. And so you've got the DevOps, the sysadmin teams are going to want to maintain.

systems that they're familiar with, that they're comfortable with, that they know, here's the way that I make it go fast, here's the way that I need to think about the maintenance of the systems. Here's how our sweeter systems all work. And so having that consistent infrastructure, I think really helps those sorts of groups. And within the Java sort of world, it's often actually the JVM is sort of the thing that's there. And so whether you use Java, Scala, Kotlin, whatever kind of cool language you want to use, it's all compiling to that JVM sort of bytecode and works in a consistent way. So if you've got a company that's using Java, how do you get them to start using Ethereum?

Yep, so I think it's starting with the idea of the distributed ledger. And so, hey, you've got this immutable data structure that you can use. And I actually led a bunch of workshops just a couple of weeks ago in San Francisco, getting people to help think about it. And it sort of started through, we would go through and teach people a little bit about blockchain, a little bit about what some of the properties of a blockchain are. And then think about how this is going to be working with maybe the consortiums with the companies and other people that they work with, starts to give that, here's why blockchain matters. And then you can talk about Ethereum because it's the program blockchain, it's got the solidity is kind of there, there's this community around it, there's all the tools that are there to help make it work.

Then you can talk about Pantheon being a part of that and being able to run that in your Java sort of world and make that fit in really well with you there. And so there's this kind of nice sort of arc that fits in well for an enterprise there. Okay. And so in my experience in the time that I spent working with Enterprise, and trying to convince big companies to start using blockchain, et cetera, sort of in 2016 to late 2017, 2018. Companies were not at all or very little, at least, thinking about using main net and using public chains. A lot of companies were looking at implementing permission chains

and building consortia, like all of this. What seems very complicated now, I think back on it, Why do you think that companies should be on main net? And is that a push? Is that something that you guys are pushing towards? I think that main net is definitely a piece of the picture for people. And so I think if you look at, and so there's a person that consensus,

a visionary and great, great speaker, John Walpert. And he has a few different great ways of being able to think about why mainnet is important. And I think there's, if you sort of look at the two security properties of, I guess, secrecy and the immutability, blockchain and mainnet in particular is awesome for immutability. And so being able to pin your data to main net, I think for organizations is really the gold standard that's there. for being able to prove that you've got some sort of Merkel-proof backing whatever hash you've written to the main net is gold.

And so I think that is really where organisations need to be moving towards. And then potentially there might be sort of private databases, private consortium networks that they're using on to sort of get to that result that they want to pin back to the main net. But I think that there's definitely this main net first sort of world that we need to get to. and how we get there, I'm not sure. I think there's probably some of those convoluted consortiums and private networks are part of the path that is still sort of sitting there for a lot of organizations.

But I think getting to that main net sort of first is really important. The way that I see this increasingly now that, like now that Cosmos is out and that we've got kind of a roadmap for Ethereum 2.0 and we're starting to piece together how, these blockchain networks will look like, sort of in their infrastructure. The way I see this is, you know, we'll have shards or side chains or whatever you want to call them zones backed by a main chain. And before, we thought, okay, there'll be these consortiums and these consortiums will operate independently. And there might be some interaction with a public chain, but it wasn't quite clear how that was going to will play out. Now that we have these sharded chains, or at least they're coming into existence,

the idea that you could have a consortium running on a shard of a main chain or as a side chain, and then that consortium just, yeah, like you said, it pegs back to the main chain at some point to establish the veracity of a transaction or a state. And then, And I think that extends to other consortiums. So you might have like a company or a consortium on a shard and then another company or another consortium on another shard. And then they can use the main chain to transact and interact with each other. Is this the future that you also envision with regards to enterprise or is this something that we're missing here? I think I think that's pretty close to it.

I think that enterprises will definitely have multiple different chains and multiple different chains that they're communicating with. Having a client that helps make it easy to communicate to different chains is going to be absolutely essential. I think the spot at which the cross-chain communication happens is going to be an interesting place for research and development over the next months and years. and so how that communication across side chains or across shards sort of happens, I think will be an interesting, interesting topic. How much of that is at layer one, how much of it's at layer two, and how things progress from maybe you start with a layer two solution and then evolve out a layer one solution will be the interesting place,

one of the interesting places for research to be happening. Have you guys given any thought to, how enterprise might also become stakeholders of the main chain. So in Ethereum, like the beacon chain, you do envision a future where large companies or sets of companies working with Ethereum, implementing side chains or shards are also stakeholders of a future Ethereum proof of stake network, or are they just tagging along for the ride and using this shared security? without any specific stake? I'd love to see them a part of it.

I don't have a strong opinion on how that happens, but I think it makes sense. So I would imagine that if staking is as profitable as it's meant to be, it's probably going to be a good place for some of these larger enterprises to keep some of their funds and have as one of their investment strategies. And given that, and they're using it, it's also then giving them that sort of safety and reliability of the network. And so I can see them sort of wanting to do it for just the straight financial reasons,

but then also because it's protecting their investments and their assets as well. Also in terms of governance, I mean, you know, if they have stake in the network, they would also be able to vote on, you know, I'm not really sure how the future Ethereum governance is meant to look like, but presumably there's some governance mechanism in there that allows stakeholders to vote on proposals and this sort of thing. Do you think this is something that companies are going to want to interact with in the future? Yes, I'm not sure what the governance model looks like in an Ethereum world. I'm not sure that stakeholders are directly going to be tied to getting voting rights on changes to the network.

But I do imagine that organizations are going to want to be able to influence the direction of the protocol. This episode of Epicenter is brought to you by Microsoft and and the Azure Blockchain Workbench. Getting your blockchain from the whiteboard to production can be a big undertaking. And something as simple as connecting your blockchain to IOT devices or existing ERP systems is a project in itself.

Well, the folks at Microsoft had you covered. You already know about the Azure Blockchain Workbench and how easy it makes bootstrapping your blockchain network pre-configured with all the cloud services you need for your enterprise app. Their new development kit is the IFTTT for blockchains. Suppose you want to collect data from someone in remote location via a SETTRAP.

and half that data packaged in a transaction for your HyperLedger Fabric blockchain. The Development Kit allows you to build this integration in just a few steps in a simple drag-and-drop interface. Here's another great example. Perhaps you're an institution working with Ethereum and rely on CSV files sent by email. One click in the DevKit and you can parse these files and have the data embedded in transactions. Whatever you're working with, the Dev kit can read, transform, and act on the data. To learn more and to build your first application in less than 30 minutes, visit aka.ms slash epicenter. And be sure to follow them on Twitter at MSFT blockchain.

We'd like to thank Microsoft and Azure for their supportive epicenter. So let's move on to Pantheon. Tell us what are those some of the interesting features that Pantheon offers. Yep. So, you know, I just start with it's a main net first client. And so I think our initial release of Pantheon was to have it running on mainnet, to have it syncing with the network and processing the latest blocks. And that's our first commitment is to working on mainnet. But then on top of that, we also think about the enterprise Ethereum.

And so I think we might talk a little bit later about the Enterprise Ethereum Alliance. And so Enterprise Ethereum is something that we take really seriously. seriously. And it talks about three P's when it's kind of really two P's in a C. So the three P's are privacy, permissioning and consensus mechanisms or performance. And so we offer, I think, really good answers to all three of those sorts of requirements. So we have a really good system in place for permissioning and being able to control who can join the network and who can submit transactions. So that's our permissioning sort of story. We've got some good tools to help think about privacy. And so being able to have a mix of sort of off-chain privacy. And so

the only thing that gets written to the chain in an off-chain sort of privacy sense is a hash of a transaction that's happened between some subgroup of parties. So we've got that sort of support and then we also sort of have tools and partnerships with some of the zero knowledge kind of tools so there's the Aztec sort of group have produced a really good sort of zero knowledge solution and so there's a blog post which we can share probably in show notes which talks about about how that works and then in terms of consensus mechanisms we've got a new consensus mechanism that we've produced that that works really well as well for a consortium type environment

Okay, so let's dive into these three P's starting with permissioning. So just to preface, for the moment at least, this privacy aspect, this permissioning aspect, and also being able to switch out consensus mechanism only works if you're deploying Ethereum as a consortium chain. These things don't work with the main chain. That's right at the moment. So our privacy solution, we've designed to be able to work on the main chain if all of the people involve, all the parties involved in the private transaction are running Pantheon. So that, that quality is not quite there yet, but that's what the solution's been designed for. That's interesting.

Yeah, as we sort of improve that, we'll be working towards that. So at the moment, within that, the challenge that we need to solve for is what happens in. in the case of chain reorgs, and how to handle that is where the challenge in that. It's interesting. Are you saying that then a consortium of companies could deploy a smart contract to Ethereum. And if they're all using Pantheon,

maybe if the smart contract only authorizes certain keys to send it transactions, I don't know if that's possible, but then you could have sort of a little permissioned, private, or private smart contract happening on the Ethereum main chain? So I think that's, so the vision is close to that, but slightly different. And so within that, that privacy sort of world, it would be, you would be able to deploy a smart contract to the main chain.

The only thing that the rest of the world would be able to see is hash, that there was a transaction that was sent to a pre-compiled smart contract. And then the other Pantheon clients would be able to interact with that pre-compiled smart contract. They'd be running the pre-compiled smart contract would then be able to look up the transaction using the hash. If there are a party to the transaction, they would be able to then execute it and be able to participate in private transactions against that state. And so your first transaction would be deploying a smart contract, and then future transactions would be interacting with that smart contract. And so only participants in that privacy group is what we sort of call it would be able to see anything more than a hash of the transaction. Okay. Are any companies doing this right now on the main net?

Not in the main net. Okay. So that's the privacy side. This is something you've implemented on Pegasus and presumably works very well if you're on a consortium chain. But perhaps you can also use it on the main chain. How does permissioning work? Yep, so the permissioning, we think about it in, there's probably three different levels. So we have some permissioning around our JSON-RPC APIs, so being able to control which accounts are able to interact with which JSON-RPC APIs. But that's very much around a specific node, that's an Ethereum client that's being deployed. then we have sort of our node level permissioning. So the node level permissioning is being able to have a white list of which e-nodes are able to connect to the network. And so that's managed via a smart contract.

And so you're able to restrict which nodes are able to join the network. And so the peer-to-peer network is not broadcasting out to everyone in the world. world, you can't just have anyone join, you have to be on that white list of e-nodes to be able to join the network. And then the third level that we've got is account level commissioning. And so this is, I guess, kind of the most real in terms of the network. And so the account level permissioning is restricting which accounts can, I guess having again a white list of accounts that are able to submit transactions that are able to do different. types of transactions. So whether it is an eth transfer or a smart contract message that's being

sent or deploying new contract, those sorts of levels of granularity in our account level permissioning. Okay. Yeah, that would make a lot of sense in a consortium setting. You know, you obviously, you only want the members of the consortium people to access the blockchain, and then you might have other permission considerations for the types of API calls that each of nodes can send to the network and then also like accounts and things like that. I can see there's a lot of use cases around that. Exactly. And that system that we've built and designed is a smart contract based approach. So we've worked with the enterprise Ethereum alliance to sort of take what we've done and work with the other organizations to make sure that it makes sense to

having a standard and set it up to be standardized, which then is, done in such a way to give a real strong split between the enforcement of these permissions, which is really well-defined, you know, well-defined interface, smart contract interface. And then the actual sort of management piece, we've sort of kept a sort of separation there of concerns, which gives that ability to use a different governance model for your consortium network or sort of squab out what sort of governance model makes sense for your network. So moving on now to the third P or C, the consensus algorithm. So you guys are working on this IBFT algorithm.

Can you talk about that and describe maybe what types of use cases it's best suited for? Yep. So the IBFT protocol, it's in the sort of has two bits of heritage to it. And so it's very much in the PBFT family of consensus mechanism. But then on Ethereum, it also has a bit of a clique kind of POA kind of feel to it as well. And so if you kind of merge those two together, you end up with the IBFT family. And so there's a really sort of active research community around the consensus mechanisms at the moment and doing a lot of security research into where some of the failure modes might be from a

a computer science perspective, which often then get proven out with sort of real world failures as well. And so our research and development team have helped us to produce the IBFT2 algorithm that we've produced. And it's really ideal for that kind of consortium or private kind of Ethereum network. It's probably not going to be the algorithm that's used for the, the, the, future proof of state kind of world, but it is going to be the thing that we're using for those kind of private consortium networks. And it's sort of, the idea there is it works great for some sort of range from four to 30 sort of validator nodes in your network, is the sort of golden sweet spot for that algorithm. So how is IBFT different from, say,

tenderment BFT where tendermit BFT can scale to more like 100 to 150 validators I think Yep so I think it's it's very much around The the recovery when there is a Byzantine fault And so the the IBFT algorithm The time to recovery when there is a fault is is smaller

And I think that's the the key sort of win that's there there's also some other potential optimizations which are available to the IBFT family in terms of decreasing the number of phases that are needed in the happy kind of path and those that that sort of optimization is not available for the the tentament family okay so you mentioned that IBFT probably won't be the algorithm that would be used for the future Ethereum Proofestate Network because obviously like 30 Evali is probably too little. But it is conceivable that IBFT would be used on side chains, and then that IBFT side chain would then sort of commit to the main chain. Is that correct?

Right. Okay. Are you seeing any specific types of applications in your dealings with enterprise that are particularly well suited for IPFT? Yeah, so it's the standard kind of, I guess, financial, defy sort of use cases are really sort of strong ones there. So one of the key properties with IVFT is the transaction finality. And so we can see that sort of consortiums which are doing anything that's kind of financially based being able to know that a transaction is final when it's written to the chain is pretty important. Right, because IBFT has finality. Yeah, that's right. Yep. So the banks are a bit uncomfortable with the idea of the probabilistic finality of the proof of work offers. So moving back to Pantheon, what types of notes do you support?

Do you full archival nodes, full async nodes? Yep, so at the moment we're a full archive node. In our recent sort of release that we had, we've added in fast sync. And so fast sync is something that it takes a long time to implement. And funnily enough. And so our fast sync is there. The bit of work that's currently underway is adding in pruning. And so that will sort of move you from being that sort of full archive node to just being that sort of full node.

And then I think the more sort of like client sort of configurations are in our future. but we're not there yet. So you mentioned standardization and the work that you're doing with the Ethereum Enterprise Alliance. Can you expand on that and let me give a status update on the EEA? Yep, so I think it's been a really busy,

probably 18 months for the EEA. They went from not having a client specification at all to their at version 3, was either has just been released, I think is the status of it. And then they're targeting DevCon, DevCon 5 for a version 4 release. And so they're really iterating very fast on making sure that there is a top quality client specification there.

And that's the main place where I work with them. They also have another number of other sort of working groups that are there. So there's a group that's working on building out a test network, which is then going to perform the basis of a compliance sort of testing suite. So the initial version of that test network is going to sort of help flush out some of the interoperability issues that they might be between some of the enterprise Ethereum clients. And then once they've got that sort of up and running, that's going to then form the basis

of a certification program. And so the EEA is working really, really hard as an organization and the the client members to ensure that it's adding value and making sure that we are producing standards and specifications of Ethereum that work well for enterprise. So how important are these standards to enterprise and how do you reconcile, because I mean you guys are building a client that's both main net compatible but also consortium chain compatible, how do you reconcile the needs of permission permissionless Ethereum world and the needs of a highly secured permissioned consortium chain.

It's a good question. So I think it's one that I think I've seen other clients have different approaches to what we've got. So I mentioned early on that we're main net first and we take that as our priority. And so whenever we do something that is enterprise, our first, our first, goal is to try and do something that works well with Mainnet and is compatible with the standard Ethereum. There can be features which that doesn't fit in. And so that does happen from time to time. So when you look at the permissioned sort of network, maybe there might be a spot where an E-Node URL moves from being straight IP address based to being DNS based, because that's going to

maybe work better for an enterprise context. Now that's going to be a change which breaks, by running your Ethereum client in that mode, you're no longer a mainnet compatible. And that's going to be a change which makes me uncomfortable, but we would probably, probably make. And so I think it's that making sure that any time we're doing something that makes our client have a mode which is non-mainnet compatible, makes us feel uncomfortable, but it might be the right thing to do. still is kind of the way that we play that challenge there. In terms of the applications that companies are building and that enterprises are interested in building, have you seen any shift in the last couple of years towards some of the applications

being built on Mainnet or are companies still very interested in building their supply chain and building out their internal processes and certifying their internal processes on Ethereum, which is something I think that a lot of Enterprise were interested in a couple of years ago. What's the state of the way Enterprise are thinking about Ethereum and the applications that they can build there? I think it's in the spot where we were a couple of years ago. People were interested in building the private networks but not doing anything because they're still just interested. I think right now we're seeing some, there we're seeing some uptake in some of the consortium networks, but there's a lot of interest in doing mainnet. And so it's kind of, they're not

quiet in the spot where, okay, yep, we're going to commit to main net, but they are really interested in it and really thinking about, okay, how is mainnet going to fit into our strategy? How are we going to do it? So it's that sort of tipping point where I think in, you know, a year's time in two years time people really will be using mainnet in a in a serious way and how would they be using mainnet like what kind of applications uh would they be using mainnet for because i mean a lot of the stuff happening on mainnet now is a lot of defy and um i think a lot of the infrastructure there is sort of supporting i would say like speculation around ethereum and token transfers and decentralized exchanges and this sort of thing what's what are the interests of enterprise

for using mainnet. So I think the defy kind of use case is pretty strong still. And then I think it's also then the using it as a certification spot for their private kind of consortium networks or their side chains pinning state back to main net. Probably the two spots where there seems to be the most interest at the moment. So but I think in Ethereum, the the sweet spot for Ethereum right now is kind of that defy, the tokenization of things is, tokenize all the things, I think is sort of where we're at for Ethereum, not just where we're at, but I think it's where we're going to be for that sort of short to medium and perhaps even sort of longer sort of future. That defy use case is pretty strong.

Can you talk about some of the specific things that maybe some of the companies that you've worked with or consensus has worked with? are doing? I start to stretch. So my sweet spot is more on the actual protocol side itself and helping making sure that we're building the right thing to support people. We are definitely seeing though some of the interesting use cases are out there. So there's Comgo is a project that is using Ethereum and built on top of it built in partnership with consensus very closely. And And so it's a commodities trading platform and a consortium-based network in Europe. And so that's sort of one of our very successful projects that's there.

Definitely seeing a lot of interest for, again, a lot of the financial use cases. So I won't name names or name projects, but the interbank settlement sort of space is quite interested in using Ethereum to help make that work well, that anywhere where there's multiple sort of large organizations that don't quite trust each other or trust any one person to be the centralization point is where we're definitely seeing a large sort of interest for Pantheon and enterprise Ethereum. Do you think that Ethereum really does have the potential to scale at a point where it can support something as transaction volume intensive as interbank settlements? Or do you think that companies and banks will continue to use side chains to do this?

So I think the Ethereum 2.0 with the sort of sharding that's there on that roadmap is going to have that sort of scaling. that you know a thousand X on top of on top of what you are doing on the current sort of Ethereum plus and that's just by the straight sharding plus the the smart things that you can do for for changing how you process transactions and do things there I think really does give that that space to provide the scale the the main net Ethereum as it is now does not does not provide it but moving forward to that Ethereum 2.0 future I think there is a world where that works well

So do you see a future where permission chains continue to exist? Or like what is the point of a permissions chain if Ethereum scales to some close to infinite level? I don't think banks want to be making the details of their interbank settlement very visible. And so I think that it's more for the, I guess, the privacy side than the scaling side is probably the, the spot. where you're going to see the side chains, the consortiums, the non-mainnet kind of chains out there. Okay, cool. So before we wrap up here, I do want to spend a little bit of time talking about Ethereum 2.0 or Serenity, whatever we're calling it now. Can you give us a bit of an update on where things stand at the moment with regards to Ethereum 2.0 and what is some of the work that you guys are

doing on that front. So I can speak more to where we're at. It's hard to, hard to know exactly where Ethereum 2.0 is because it's hard to keep up. But the, the bits that I can definitely see is the, there's the three phases, phase zero, sort of starting off the beacon chain, phase one sort of introducing the sharding and then phase two with the execution environment. I think phase zero is getting into a very good spot. And so there's a number of test networks that are out there at the moment.

There's sort of plans in place to work on how to get those interoperating with each other and getting the clients talking to each other and working together really well. There's a recent sort of announcement about trying to get a staking contract out for DevCon and then looking to get this sort of released in early next year and getting like really a beacon chain running in a production environment early next year. And I think that some of those timelines are aggressive. I think that there are great stakes in the ground that aren't just going to slide. As in I think that maybe the date moves from like an early January to like a February,

but it's not going to be like we're not going to be sitting here at this. time next year and saying, oh, what's happening with our beacon chain? I would be absolutely shocked if we didn't have a beacon chain running very well by this time next year. Yeah, that's really encouraging to hear because the last time we talked about this on podcast, I think, I mean, of course, beacon change is one part of it, but, you know, there was this expectation that Ethereum 2.0 could take, you know, two to five years until it's ready. Maybe maybe that's still the case with all the other layers that need to be added. I'm going to ask you the same thing. I think I think I asked this to Joe Lubin.

Whatever Joe said is right. If Ethereum 2.0 does take so long to bring into production, I think the estimates are somewhere around like two to four years or something like that until we're like ready, ready for production Ethereum 2.0 network. There are other blockchains out there that are doing similar things to what Ethereum 2.0 wants to achieve. so Cosmos launched a couple of months ago, and there was just this big, like the first Cosmos event.

Pocod will presumably launch before that as well. What are your thoughts on Ethereum's dominance as the predominant DAP platform and how that predominant, like how Ethereum could potentially lose some of that predominance if it takes too long, to move into production and these other chains are ready and people can build on them. I think it's a real risk for Ethereum and one that we need to take seriously. I think that that said, I think that there is sort of that that weight of the community already in Ethereum. I think that that's why, as well, Pegasus is taking a really strong, two-faced sort of approach of really pushing hard into that enterprise sort of space.

And so by going out into the enterprise and reaching out, particularly with our Java client, being able to reach out to the Java community, like most of them have hardly heard of blockchain. Maybe with the new work of our friends at Facebook, everyone's going to know about blockchain now. But I think that it's more about growing the community. and so within that enterprise kind of context,

there's no sort of issues with scaling. There's the well-known, well-established tool chains that are there for doing the smart contract development in Ethereum that I think a really good story for us to be able to communicate with that enterprise community. And I think that, so that's one direction that Pegasus is working in and then also working very hard on that Ethereum 2.0 research, but also making sure that we are shipping software with Ethereum 2.0.

And so I think making sure that we are building stuff that proves that the research is either right or wrong, rather than keeping it as theoretical. So I think that those two things are the best things that we can be doing to make sure that both Ethereum works well now and that the future of Ethereum 2 or Serenity sort of comes in the right sort of timeliness. And are you guys working with the folks working on Ethereum 1.X? Are you also interacting with that team? Yep, that's right. Yep.

So we had a number of people going along to some of the workshops and trying to help bring that forward to have that sort of, I guess, bridging between that Ethereum 1.0 and making sure that it continues to scale for long enough to keep the main net running well. until Ethereum 2.8 comes. And can you give us an update on the progress there? Are you aware what's going on on that front?

So I think there's a bunch of really good proposals that are being worked through, which I don't think too many of them have made it into the form of EAPS yet. But that's sort of the way forward is to go from those sort of working through what is possible to producing the EPS, which can then be reviewed and improve So it's still in that sort of earlier phases of that, but I think it's probably going to be the things that we would see in the hard forks that happen next year on the main net Ethereum clients. Or main net Ethereum network.

Okay, cool. So tell us where can people learn more about Pegasus and Pantheon and anything you want to plug at this point? So I think the best two places, the website is Pegasus.tech and have you a good look there. And then for probably an even better spot is our GitHub. So the the GitHub.com slash Pegasus Eng and Pegasus Eng slash Pantheon. And so we'll put URLs in ways that are easier to parse than listening to me spell them out. But those would be the two places to go. And then if you're really kind of keen and interested in what's happening in the beacon chain, the Pegasus Eng slash Artemis on GitHub is the place to go there. And are you guys hiring?

Yeah, I think if there's people that are blockchain engineers, people that write Java and like to are interested in contributing to the enterprise Ethereum client, definitely would love to have a conversation. All right, Rob, thanks for joining me today and looking forward to seeing the developments on Pantheon. Thank you. It's been a pleasure. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud,

or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guest or other podcast, listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people

find the show and we're always happy to read them. So thanks so much and we look forward to being back next week.