B (3:58)

Thank you, I appreciate that. Certainly helps me, helps my audience here understand. But as you mentioned, I've just highlighted a few things. People tend to solve future problems versus today problems is more hype. And the other big thing that I took away is as you know, it's hard to change people's behavior. So you look for world problems today that you're able to solve and maybe influence people's behavior. And there's, I would say I'm paraphrasing the difference between solving those hype problems or a real world problem today. So thank you. And Jeff Wright is positioned as a purpose built layer one for institutional grade performance and compliance. What gaps did you see in existing blockchain infrastructure that made building a new layer one the one only viable path forward?

A (4:49)

Building a new layer one was required in my opinion simply because the existing blockchain world was more academic in nature than it was real world utility. So it's out to prove attack vectoring management.

A (5:04)

Scalability. When it comes to cryptocurrencies or tokenization as we like to refer to it, none of those things actually work in a real world setting because they're academic in nature. They're not actually addressing what would be the requirements of the business sector that they'd ultimately have to serve. What are those requirements in general? Those requirements are speed. When you look at the Visa MasterCard network, you're looking at 2700 transactions per second on a worldwide basis. When you look at most blockchains out there, whether it be Bitcoin or ethereum, you're looking at 2, 7, 27 transactions a second. They don't operate nearly fast enough. When you're looking at the banking industry, which would have to be an edge portion of any real world utility solution, you're looking at small epics, something that the blockchain world refers to as to determine finality in a record set. What is the current truth, if you will, on that blockchain as a distributed lender. Thus, existing layer ones like Bitcoin, Ethereum, et cetera, their end banks are too long. You need something in the 100 millisecond range to satisfy a banking operation. When you're looking at Bitcoin, you're looking at 10 minutes. So if you are creating a real world utility around spending and you're sitting at a Walmart and you're trying to swipe your car that's attached to your Bitcoin blockchain, Walmart's not going to wait 10 minutes for finality on that. So you have to have a much smaller epic if you go for finality. And then you have footprint issues, right? So you actually have heavy network traffic and heavy clients or nodes sitting on hardware out there. This is why you're looking at $20 million rigs that are actually the ones that are contributing to the Bitcoin consensus model as validators. Most often you can't afford to have those types of machines out there. Most people have a machine at the phone level, right? Something that might be a smartphone doesn't have that kind of capacity nor bandwidth, nor processing power. So they are not real world solutions because it can't be run on real world hardware. Nobody's running $20 million rigs in their backyards there. There's issues with that. Not only does the throw credit too big, processing power requirements of some of these consensus models are too large for real world utility. So you have to change that significantly. Then you're looking at security issues, right? Ranking and other types of edge processing is going to have tremendous amount of regulatory issues that they need to comply with. And if you're looking at a layer one chain that isn't built from the ground up to comply with those same regulations, you're going to have some very serious challenges later. You're not going to be able to pass their security protocols. And it's not just pen testing and it's not just making sure that your smart contracts are working, has to work in their entire client's chain. So we don't have any blockchains out there that have been built from the ground up specifically to manage the regulatory environments. And then security, security tends to be an Afterthought once they get breached, then they'll start to add layers on for security purposes. Layering on security is never ultimately the proper full on solution or approach. You should be building that from the ground up inside of your actual designs. It should be an initial part of your architecture, not a secondary card or an afterthought. So you have a variety of blockchains out there that have made some very serious promises. You have those that are even promising governmental level deployments. But how come they haven't? And the reason is, is because every time a government actually does a deep dive into those existing blockchains, they find that sure, you'll pass some basic pen testing, but you're not actually designed from the ground up to manage what would be a real world setting. You're not managed or built from the ground in to actually manage what would be the true attack vectors that are coming from what might be other governmental agencies from around the world that might have heavy resources available to them. This isn't somebody in their dorm room that they're trying to make sure isn't attacking their systems. They're looking at other governments who have almost unlimited resources, who can mount surprisingly large attack vectors. And this is something that they are looking at. And then you'll see most of those blockchains fall by the wayside. So we had to build something up from the ground with our 40 years of experience in the banking industry and in work at the government side to say there's a certain number of requirements here that just are, must and are currently being missed by all existing blockchains.

B (10:19)

Thank you, really appreciate that. Just to highlight some things again, Jeff, you knew layer one was required a whole change because what you saw was more theory or academic, not real world. And you knew that infrastructure would need to be reliable with high throughput. As you talked about a few examples there transactions need to be within milliseconds and also platform needs to run on real world infrastructure hardware that you talked about. And of course compliance and security are key, they're critical and these must be built in from the ground up, as you mentioned. So I appreciate that, Jeff. Many blockchains claim scalability and security, but few deliver both at institutional levels. What technical breakthroughs or design decisions with write enable high throughput without compromising trust?

A (11:08)

That's a great question. It's very difficult to actually manage those in parallel. We've managed to do it though through redesign. Some of the things that are important in there is to get rid of the gas auction. So all blockchains right now, particularly those that are value driven, will process transactions based on an auction system. Essentially who has the most fees or gas attached to a transaction. And that's the one that we're going to handle first. That doesn't work in a governmental setting. I need to know that all transactions are being managed, that they're being managed in order and they're being managed across a distributed ledger in that manner. And when you create an environment where you have a single entity or a node at any given moment, which is what a proof of work or a proof of stake consensus model dictates, then you create a built in bias to what transactions should be processed. And that will immediately disrupt trust because I am not sure as an operator or a user of that system that my transactions guarantee to be processed and guaranteed to be processed in order. And so we have to change that as a fundamental piece. So we did do that. You have to have native zero knowledge support within your protocols. But most blockchains fail to manage is the overwhelming amount of data that they will ultimately create in that quote blockchain, that chain of blocks. So you'd have to be able to manage that. And mechanisms for managing that don't include reading the entire chain every time. There has to be an indexing model. There has to be a mechanism for zero knowledge proof to determine that the information that you're getting is true and accurate without having to go through an entire history of a blockchain. So new mechanisms had to be designed to actually support that. So we use those words as part of our normal nomenclature. But most blockchains, if any, are actually delivering on those types of of indexers and zero knowledge based proofs to actually get through what would be an overwhelming amount of data. We're also doing something truly parallel. So we're actually doing multi state execution, not this sort of execution in guys as parallelism. Something that is truly run in multiple lanes. The way that we're doing that is each node in our network actually participates. We call our consensus model proof of majority, not proof of work and not proof of stake, not where a node is selected because they could do the most work or because they put up the most capital. But instead a truly democratic solution where all nodes are participating in defining what is the true state of the blockchain. The effect of that is that all nodes are actually at any given time participating in parallel. True parallelism is what we need for multi state execution to occur. This is where you get that speed. You already have a tech factor management, you have understanding that Transactions are being processed properly. And you know that you don't have to manage the entirety of a blockchain data set all at once. So you have speed. That parallelism and that voting solution will give you the trust part of this, right? So now as an operator with a layer on top of our blockchain, the right blockchain, you can have both. You can have the speed of parallelism, you can have the understanding that multiple sources are validating the truth, not a single source at any given moment. And you can have the comfort that you will have not to deal with the entirety of a blockchain's data set. Those are important things at a governmental level. They're important things to the banking industry or any seriously regulated industry. We need to know with certainty that transactions are being processed, that they are actually immutable, that the truth is not being compromised. Because I have multiple parallel lanes determining that truth and coming up with a consensus, which is the word that we use, instead of proof of stake or proof of work, which is not a consensus, that's a misnomer. You have a single node in a network creating that proof of majority. Consensus is a true consensus. It is the entirety of the network determining what is the true state of that block's chain and thus underlying data set. So we can affect high throughput, but create confidence that everything that you think is happening is actually happening. And that's where you get both of those pieces in a governmental or institutional deployment.

B (16:30)

Thank you. Just to highlight some things, I think it's pretty, pretty neat how you impact all that. But the two things centered around the question was managing scalability and security, which is very hard to do, but you were able to do that with your design and some other things you talked about that guaranteed processing transactions in the order they were received, zero knowledge, truth. And what was really interesting is that proof of work, proof of stake, which we all familiar with. You talked about proof of majority, which in your words is really the true state or consensus on the blockchain, which I thought was interesting. So thank you for sharing. And Jeff, last question of the day, if you could briefly share, looking ahead, what does the future of compliant enterprise grade blockchain infrastructure look like? How will it reshape digital services, global markets and the role of digital identity in the next decade?

A (17:19)

Well, that's a kind of a loaded question, right? You're asking us to look 10 years into the future. I would say that you're going to see blocks of changes, right? We're going to start to see a set of pilots that have been embraced at the governmental level move into actual production. That's going to take a few years in and of itself. You're going to find citizen wide deployments across an entire country. Remember, when you're talking about countries, you're talking about millions or billions of people and I'm talking about a few hundred thousand users coming on to some kind of a dating app or something along those lines. We're talking about real world, very large scale deployments. It's going to take time to move from pilot to production. I think that'll be sort of phase one. Then you're going to need to see a crossing of the regulatory issues, some kind of mounting of those regulatory compliance frameworks from country to country. Right now the biggest challenge that I think we're going to face that nobody's really talking about is you're going to have a blockchain, requirements that differ from country to country. And what are you going to do with your blockchain that is cross border employee, that's actually deployed in multiple borders with completely different regulatory frameworks. How will that be addressed? And that's something that's going to come next. After we go from pilot to production, we're going to figure out ways that are going to create cross border compliance, not just of cross border usage. And that's something huge. That's going to require something outside of a technology. Addressing is going to require us to address governments at the policy level. And that's something where you're going to need some bigger groups to come in and lobby and make those changes. That's going to be nest, that's going to be a requirement. It's going to have to happen, but it's a big task that it'll happen later. Then I think that is going to be true interoperability. Right. We already have this semblance of interoperability because we're creating bridges and we are basically saying, okay, here's how I convert X to Y. And that is what we're affectionately calling in bridge. In our technology space, the bridges are where you're vulnerable. If I were hacking a system, I wait for you to put value onto a bridge and then I would corrupt that value before it got to the next chain. So moving value from one chain to another, interoperability is something that doesn't actually happen today. It's a bridge that's making that and affecting that. We see that as interoperability, but that's not true interoperability. So we're going to need to see that happen where we actually have protocols that can scheme or free without the use of a bridge, where they can actually manage what would be attack vectors. Because that's a theme. That's the place where I would attack if I were hacked. And we're going to have to see smart contracts and other virtual machines. If you wrote the interoperable, it's going to have to be a common language so that I know that if I have a contract on this chain, if I were to move it to another chain, it will operate there. So, so true interoperability, not just for transfer of value or data, but also smart contracting and these virtual machine mechanisms that make sense.

B (21:03)

Yeah, that's great. I love that and I love to get Again, usually my last question on the podcast is to ask a guest what their insights or their crystal ball is. And I thought it was really interesting. But you know, these you talk about the next few years will be changes or pilots that will actually move into production later on several years down the road. But production will be very large, very, very scalable. Obviously you talked about real world deployment of millions of people in terms of entire countries and then you got to manage that, that cross border compliance. Right. And security. But in the end, the goal is to have that true interoperability where smart contracts can work on the various networks. So I appreciate that. And Jeff, it was such a pleasure having you on today and I look forward to speaking with you real soon.

A (21:51)

Me too, Brian. I hope that I'm here sooner rather than later.

B (21:55)

Bye for now.