 So Pantheon is a new Ethereum client built with the JVM. Because we built it from the ground up, it's Apache 2 license. We quietly open sourced it over the weekend. It's now fully open sourced. You can check it out. We'll be sharing the repo later. We had a few crawlers find us over the weekend and commit PRs, submit PRs and get them committed. So we're up and running. It all works. It runs live on Mainnet, on Rinkeby, on Robston. There's proof of work. There's click POA. It's a real functioning client. We integrate with a bunch of other consensus projects, with Infura, with Alephio, with Truffle, Metamask, and a bunch of non-consensus players in the ecosystem as well. And we're always looking for more. So the final point that I just want to say on what we are and where we are is this is our first release. We wanted to release early so we could get feedback and help the community shape what we're doing. So please play around with it. Please realize it's a work in progress, but please work with us to make it better. So just to prove that we're real, this is a snapshot we took this morning from ETH Stats and lo and behold, there we are, running both our own nodes and running on Infura Pantheon nodes, which for us is pretty exciting. It works. It's real. We're not making this up. So why did we do this? Why did we spend the last year building another Ethereum client? A couple of reasons. First, we believe that a healthy ecosystem requires a number of clients. We want a diversity of approaches. We want a diversity of techniques and teams, all contributing ideas, and so we thought another client could really contribute. The second bit though is we really wanted to build our capabilities from the ground up and get into the weeds of the challenges of building a client. That's really important for us because it provides a foundation for a lot of the research efforts we're contributing to as well on Ethereum 2.0 work as well as some of our enterprise research. And the other bit that's really important to us is we want to help grow the community. Ethereum wins and Ethereum works and thrives because of the community we have. And so by enabling another language and another team and another set of developers to work with the community, we're hoping to grow and help this community thrive. But the final bit is we also wanted to bring enterprises to Mainnet and help facilitate enterprises working on Mainnet. And so we built it from the ground up to be Apache 2.0 licensed out of the box. Any enterprise can take this and play with it. And so drilling a little deeper into this, we chose Java for a pantheon for three main reasons. The first is that Java is a really mature ecosystem and it comes with a lot of free tooling. Database integrations, other sorts of integrations, instrumentation monitoring, logging stuff that you just get for free out of the box with Java, which is really exciting. But it's the second and third reason that excites us the most. Java has an enormous community of developers that aren't engaging sufficiently in Ethereum right now. And they're usually enterprise developers. And so we're hoping by delivering enterprise-grade software we can help port them over here. And the final bit is enterprises have invested in Java. They have Java systems. They have Java talent. And it's just easier for them to play around on Java. And so I'm going to hand over to Shahan. He'll talk more about our enterprise vision as well. Hi, everybody. So one of the reasons why we... So why is Pegasus building Pantheon? Well, when we started getting involved in this space, we were involved in the founding of the EEA. We were getting involved with enterprises forming the enterprise Ethereum Alliance vision. And we were hearing from enterprises that they wanted to use Ethereum. Well, no kidding. It's a great platform. It's robust. It's resilient. And we wanted to hear their requirements. So we were trying to ingest their requirements into the EEA vision. And then from there we started working with customers. We engaged with the government of Dubai. We were hearing from the government that they wanted to use enterprise-grade Ethereum. And they also wanted to use Mainnet. Well, no kidding. And so we wanted to bridge these two disparate worlds. We wanted to build enterprise-grade Mainnet technologies that would integrate and interoperate with enterprise technology stacks. And that's why Pegasus was founded in order to build Pantheon from the ground up in a way that enterprises would be able to incorporate into their technology stacks. So where is Pegasus? Well, Pegasus is a global group. We're a group of 50 people in Australia, Europe, and North America. We have three main prongs. We have product, which is building Pantheon, which is focused on Mainnet. Mainnet is our number one priority. And at the same time, we are building enterprise modules for Ethereum, enterprise-grade Ethereum. And at the same time, we're doing research and development with the Ethereum Foundation. We're focused on Ethereum 2.0. We're focused on enterprise Ethereum. We're working on enterprise modules like interoperability, scalability, working with existing technology stacks. And at the same time, we have a standards group that is helping to bring Mainnet standards into the enterprise space so that enterprises can have trust that they can use Mainnet technologies in their technology stack. And now I will hand it over to Rob, who will talk demo Pantheon and talk about the roadmap. So while it was kind of cool showing like a screenshot of eStats, it's actually kind of nice to see software as well. So I'll start off by showing we've created a quick start that we ship as a part of Pantheon and I'll start by just running that up and I won't stop it first. It's already stopped. So we'll start with the running the private network. So this is just a series of Docker images running a few nodes and a nice little block explorer that's been built by Alethio. So as this is started, I'm going to quickly go across and go to our acceptance test. I guess our software really seriously, we've got a great set of acceptance tests that we are regularly running on commit and then some extra acceptance tests that we have sort of running as well. So Truffle is one of the tools that we think is pretty important for us to be able to support and so it's what we're running. And so I'm going to use that and we're going to kick off, we're going to get some transactions happening in our chain, we're going to get some things happening, things are compiling and working there. You'll see up there as well in the blue we've got a series of services that are running on our QuickStart. So we've got a HTTP endpoint. That's what our Truffle is interacting with right now. There's a WebSocket endpoint. So that's supporting the PubSub API, which is sort of well known and being more well established now. And there's also the block explorer sitting there as well. So I'll go through and show you our connecting into the WebSocket. So it's just using a normal simple WebSocket client Chrome extension sitting here. So I'm just going to open a connection to that WebSocket and send in a e-subscribe telling it that we're subscribing to the new Heads events. And if the demo gods are kind we'll start to see some transactions coming through and there we go. We've got blocks being created. Switch across now to our block explorer which ships as a part of the test network that we've got sitting there. We should start to see that the best blocks numbers will be increasing there. So you can see that the blocks are going through. This is a new block explorer that's being produced by the team at Aethio. They're going to be open sourcing this and making it available for people to have on their own private networks as well. So you can see it's kind of a nice clean simple interface that we've got sitting here. If I go into that best block, you can see there, so we've got six peers on our network. So that Docker network that I have sitting there has six peers sort of sitting in connecting, talking to each other. Our best block is sitting there and you can see that the current head block there doesn't have any transactions in it. We're mining pretty rapidly in this network so that we can keep seeing our transactions come through. If I go down to here, you can sort of see the nice interface there. You get kind of a length of here's how many you can see. So if I click on one, you can see there's our transactions and then we can drill down and actually see the details of one of our transactions. Let's get some of the details of what's happening here. So that's us with a live block explorer interacting with Pantheon our new mainnet client. One last thing is I want to highlight here is just we've got some simple documentation where we're working towards making this an accessible client for people to get working with and using easily. So we expect that, I guess, if we're pulling people in from the Java community, they're going to know nothing about Ethereum. So that quick start is a great way for them to get started. Our documentation, we're making it easy for people to get started and working with the product. This is, I guess, an area where we'd love to get feedback. So if people are downloading and getting started with Pantheon, you're going WTF? What's happening here? Then we want to know and get feedback and know how we can make this thing better. That's our demo. Let's have a look at some of the stuff. Yep. It's just a test net. So, yep. Okay, so we've got our roadmap here of things that are happening. So there's three main themes that we've got happening as a group at Pegasus. So we've got our core client. We've got our enterprise features and our Ethereum 2.0 work. We take mainnet as the message has been. We take mainnet seriously. And so we want to make sure that we are having mainnet as our first-class thing. It's mainnet first in our client. We've built mainnet support. We have this vision for an enterprise client that will be used by enterprise. And it is enterprise grade, but mainnet's first. You've got to build on top of what's there. And a world where enterprises are pinning their technologies, maybe using side chains, like we've got in our enterprise stack there, but pinning things back to mainnet and it all sort of works is the world that we want to enable with Pantheon. And so that's why we're doing what we're doing. So core, our two sort of big things that we see in the short term there. We don't have a fast sync yet. So we're running as a full archive node. It's our alpha. That's where we started. We're going to build on top of that and be running as a full node and getting the sort of fast sync E63 sort of messages working well and working on performance. So working with the Infero guys and making sure that Pantheon is working well enough to support the billions of requests that are coming in through Infero. We'd love to have Pantheon being a part of that and we're working with Infero to help make that happen. On the enterprise side, so there's a bunch of things happening there. I guess the interesting one. So we're doing a PBFT based consensus mechanism. We've got some really smart guys, way smarter than me actually doing the formal definition of that and doing like the liveness proofs and making sure that this protocol that we're specifying up there that's PBFT based is really sort of robust and a good protocol for us to be using and building on top of. We're looking at the EEA, so the Enterprise Ethereum Alliance, they're specifying a bunch of stuff around the consensus mechanisms but also the permissioning and privacy side. So we're doing our own recommendations of those standards and making sure that our client is ready for enterprises to start using and provides the features which we know that they really care about and need. Looking as well at the side chain side, so I guess being able to support that as we go forward with the future. The last section I've got down the bottom there and last but clearly not least is Ethereum 2.0 and so Pegasus has a bunch of work that we are doing in the Ethereum 2.0 space. We've got Ben Edgington is probably not here but he's I guess got a team around him that's doing really great work in the research side and bringing that forward into the development side as well and so our Pantheon client is going to be an Ethereum 2.0 client and so we're doing the work on the beacon chains, sharding and all the Ethereum 2.0 research and bringing that forward into our development space that's our roadmap. So looking at that, there's a bunch of ways that we'd love to get people involved. For anyone that's enterprisey and working at places in enterprise we're looking for companies, partners, clients that we can sort of partner with to make sure that we're building the software that's the right software for you. We want to make sure that our code is not being built in a vacuum off to the side by a bunch of ways. Like I'm on the product guy saying let's actually build stuff that solves problems and meets client needs. So we're looking for people on the enterprise side there. We're looking for I feel almost like Steve Volma but like developers so I won't say it three times but and I guess into in a bunch of ways. So Pegasus is hiring, we'd love to have people join our team and come work with us but also we don't want to be the only ones doing work on this product. We'd love to have an open source community and be working with a community of people. So if you've got ideas, things that you want to see in a client, come along, contribute, create pull requests we're open source, we're Apache 2 we're there to work with you. I guess the other thing for the developers is download us, use us and tell us what doesn't work. Tell us what's hard. You know it's an alpha. It's actually a really good alpha I think but it's still an alpha and you know things aren't going to be perfect and we'd love to get feedback and we want to make this like the best client. I am going to hand over to Shahan. Thank you Rob. So we are on GitHub. We are open source please submit PRs. We have already received a PR from somebody out there in the world and we've accepted the PR. Join us on Gitter, on Twitter visit us at the booth. We are close by and we are hiring. We are keen on talking to you developers, enterprises, product people. We want to ingest your ideas. We want to chat with you. So please talk to us talk to Rob about product, talk to Dan about engagement about strategy talk to me about research, talk to Ben about research, please just talk with us, engage with us. Thank you. Thank you very much guys. I think you're doing a hackathon too. Are you doing an accident this weekend? Just before we open up for questions we're going to take questions now but if everyone who is a member of Pegasus could raise their hand there's a few of you in the room. Feel free after this talk to go up to any one of them if you have any questions as well. And we're going to be at the booth, the consensus booth which is just in the sponsor zone right at the end of this hall all afternoon. And as Jerome said there's an enterprise hackathon this weekend that's here in Prague so if you're spending a few days in this beautiful city and don't want to see pretty sites but want to hack instead come join us we can give you all the info at the booth. What a sales pitch Dan. Yeah I know. It's going to be raining this weekend I think. There we go. So we'll ask a question. So for interaction with Pantheon will people use a Web3J library or is it something else that you all have created? Yep so it's the standard sort of APIs are the main way to work with it at the moment so Web3J Web3Js are the ways to go right now. I expect in the fullness of time there will be a more direct API for Java people to interact with but right now Web3J works really really well. Web3J is a part of our acceptance test sort of suite. So you think that like in the future that Pantheon will be maybe a library that you bring in to whatever Java project you're doing. Cool. Thank you. What do you think about using Kotlin to get most of the Java benefits but you don't have to write this language? Yeah I think Kotlin's definitely we've got people that are really excited about Kotlin and looking at it for definitely some of the parts of the code base and I think as we start to build more and more modules I think Kotlin is probably my preference over like a Scala so there'll be some people I think maybe even on the stage who might say that Scala's a better choice than Kotlin but we're open to all. It's JVM so yeah. And we're actually already in the process of transitioning to support Kotlin. We're revamping some of the infrastructure to do that. Are you going to provide cooperative support like greater corporation standard and a corporation support company to support companies that want to use your software? The short answer that I'll give is yes and Dan might say more. So absolutely we have a support offering that we're already working on if you're interested in that. We'd love to chat a little bit more and we can talk through. The truth is we haven't rolled it out yet so the details of it we want to talk to enterprises and understand what you'd be looking for as we define it but absolutely. Hey, that's so exciting. Thank you. Did you start working on fast sync yet and if not are you interested to collaborate with the guest team, the parity team on maybe solutions in this regard for future proof? Yes, so we haven't on the product side started doing much CASPA related stuff but Ben Edgington has been definitely looking into it and I definitely love the idea of collaborating with people. Yeah, and with the fast sync we're working on having that interoperability, that extensibility in the network protocol for example on the sync mechanism. Did I hear interoperability in sync mode, fast sync mode? We're looking at interoperability at different layers so the network layer, the EVM layer because some enterprises may want to extend the EVM in some fashion such as integrating their databases or big data frameworks or AI frameworks. The use cases are still open. We'd love to hear the use cases that enterprises would love to engage on and the more we talk with customers we'll understand where, at what layers we can develop those APIs. Just wanted to add to something that Afri said about fast sync so with the parity team and the gas team wanted to collaborate on a new sync protocol and if you guys are interested you're more than welcome to join in about eight minutes on the discussion of where to take the whole sync protocols because it's a really pain point for everybody so. Do you have any questions? Do you have any questions here or? We're not sure yet. Somewhere. Grab me. Yeah. One more question. Have you reused any of the code or you have started from scratch? For licensing reasons we started from scratch. How do you integrate integration for example? Not currently but I guess we've got a short term roadmap and then open roadmap beyond. So even though we're not supporting OSGI it works with spring so dependency injection works very well with the framework as is and it's very easy to use so very easy to extend and apply. There's probably a PR sitting on the roadmap. Is that for future quorum support? So we're using an IBFT based protocol and so the potential for interop with quorum is there. The actual details of how that's going to work is not yet I guess developed and so it's hard to say how it's going to exactly work. While we have an IBFT implementation and it is interoperable we're working on an IBFT 2.0 which is meets better constraints for liveness and safety. Do you all have on your roadmap a plan to maybe improve the privacy features of private transactions in quorum? Can you talk about what you all are doing there? So we definitely have the ideas around how to do a privacy in a way that's I guess different to quorum and so sort of inspired by or learning some of the lessons from quorum but done somewhat differently and the actual implementation details are still like a broken record. Haven't got it actually done yet but there's definitely some diagrams and things that I can share with you and have a chat with later. And the EEA spec v1 was released in May v2 was released yesterday. They have privacy levels. So we're going to see how quorum's privacy and our privacy features may interoperate or just compare and see how we can perhaps support the EEA standards as well as customer requirements. They may not overlap so we're very curious to hear what kind of privacy requirements that you're seeking. So please come talk to us. It also might be worth I mean you might have thought about this but creating a bounty to see if you know there's a lot of different ways of creating a bounty to see if you know there's a lot of information on this private transaction so it might be a good idea to like try and open that up just to make sure that banks and insurance companies are you know are comfortable with that. Yeah definitely. Just a thought. Yeah I mean our R&D team the ETH 2.0 team they're working on ZK Starks and ZK Snarks trying to figure out these are all pieces that we're all actively looking into. What kind of technology are you using for the chain data storage? Yep so at the moment we're still working on a ROXDB sort of database for the storage. We're looking at so we've got an abstraction layer around that and so moving into support I guess a you know pluggable storage mechanism so I guess it's Java so probably we're going to do a CBC based with the caching layer to actually make sure the performance happens as well. Yeah and the R&D team is also looking at database technologies to try and simplify the integration and the indexing benefits that come from databases. So we're trying to see where the technologies can be leveraged in the blockchain and vice versa because that's how we're trying to bridge we're trying to bring mainnet