Now a lot of stuff had to be thought about for example turns out if you use technology like Mithril and also extended UTXO that this helps you figure out how to do this in a way that it resembles this type of system especially as you zoom out, but you get the throughput of this kind of system.

It's easier to draw it, it slows me down a little bit, and also it allows us to have no ambiguity, which is very important. Right now, we have the IO repos, and they're going to move over to the Intersect repos. At Input Output, we have this concept of tribes, and each tribe is connected to a different concept like smart contracts, for example, core technology. Smart Contracts covers things like Plutus, Marlowe, extended UTXO, core technology covers core node, network, consensus, we have tribes like identities, sidechains and so forth.

The basic idea is you establish a technical baseline showing you know how to read and actually work on the code, you establish a baseline for how everybody works together in the system, and then you establish a baseline for how Cardano works under the hood. Network protocol, extended UTXO, how Plutus works, how Ouroboros works, all the APIs etc etc. So, basically these type of things will get you up to speed as a core dev. So, if they are designed correctly, you should be in the position and demonstrate enough technical skill that you should deserve credentials.

And there's a lot more to love there extended UTXO, Sigma Protocols, they have. A pretty cool proof of work system. And it’s all in Scala, one of my favourite programming language.

Let's take a look. eutxo.org. OK, do it all from time to time, but I do so because it really does prove a point. This is a live view of the Cardano network right here. So, let's take a look kids together. So, it's loading data from the Cardano network.

So that's the model and when sidechains come in, you have completely different execution models. You can merge accounts and extend UTXO together, you have the EVM over there, but they're bulk headed. So if they fuck up the world and everything blows up, it's that thing over there. It doesn't cascade and destroy the main network. It doesn't bring the main network down. And so, they get better, faster, cheaper. And then rollups come.

So, when we look at other parts of Cardano, other parts of the system, you have UTXO HD, you have Genesis, you have the remaining work streams on peer-to-peer. So peer-to-peer is is done from the perspective of peer sharing and the actual peer-to-peer mechanics.

...and that's going to be running in parallel with the core team that does 1694. The same for UTXO HD, which is a different way of storing things so that you can utilize a persistent storage, a hard disk in addition to in memory storage. These were both critical path items for complete decentralization of the system, so they're kind of first-class citizens with CIP1690.

And so we're writing papers right now along those lines. And there's a beautiful combination of concepts from parallel chains and prior papers, the extended UTXO model and Mithril certificates and putting these things together, so watch for that throughout the summer.

So that's why a lot of the dapps and define Cardano are so novel, interesting and innovative, because they've actually had to redesign and rethink their protocols from the perspective of extended UTXO and for Plutus.

Second, we're going to really double down on this whole concept of having an advanced user mode for the Cardano wallet. So, we're going to have a terminal and that terminal is going to allow you to do things like manually construct a transaction, manually do UTXO selection, run scripts that you can write kind of like a shell script within the wallet.

And because it's been built in a very particular way, it may be abstracted to a point where you can use it for any UTXO wallet, if you load a certain parameterization into It, meaning that you could conceivably, in the long arc, use this as a Bitcoin wallet system or a Litecoin wallet system. In addition to being useful for Cardano and so forth.

So basically, what would happen is it would download a small amount of data, get the UTXO and then you'd instantly be able to use Daedalus as opposed to having to wait for Daedalus to download the entire blockchain.

So, you can run a script you can, check the blockchain, make sure that your database is not corrupted. UTXO defragmenter, so if you have some fragmentation or you need to consolidate down so you don't have all these dust inputs, there are ways to do that and there's scripts you can run to do that.

And one of the things we wanted to do before we got there was first have a really deep understanding of how expressive our UTXO model was going to be. So, we needed to create Plutus and Marlowe for that, second, we need to have a really good understanding of how we wanted to handle both delegation and voting. These are the ingredients that go into address complexity.

It's just a situation where you need to have a lot of engineering and a lot of progress in place before you get there. So, we needed to create the extended UTXO model. We also needed to create a variety of of of things related to delegation and so forth to functionally get there. But it's on the way.

First off, we're going to see a terminal work its way into Daedalus, and that terminal is going to be very verbose. It's going to let you do lots of amazing things directly. Talk to the cardano wallet backend, manually construct transactions, do your UTXO all of these great things. Just beautiful thing. People going to be really happy with it. It's going to be insanely great. Best terminal we've ever done.

So, the core of the system is an implementation agnostic collection of mathematical representation, and any developer should be able to take that, read it, understand it and say ah, I understand what you're talking about when you say this is a valid transaction versus not. I can reason with this fact to understand one versus the other. From the UTXO set to the Ledger rules to how consensus will work and how the network will work - that is the soul of our protocol.

So if you look at the Rust client one of the cool things you can do with the rest client is that you can manually construct transactions, eventually can sign offline transactions, manual UTXO selection and this idea of a wallet scriptlet...

Allow you through that terminal to interact with wallet layer and giving you the ability to have an advanced user mode where you can manually construct transactions, do offline signing, do UTXO selection these types of things in addition to running your own scripts inside the system and eventually coming up with a clever way of packaging them and deploying them so we can talk about automated wallets...

We've seen a massive improvement in UTXO selection and now we have a system that will not fragment.

This includes things like multisig. This includes things like manual selection of the UTXO, manual transaction creation, offline transactions.

So, there's still a lot more to do. There's still a lot more testing to do, but the concepts like extended UTXO, how Plutus works, how to integrate Plutus, how to integrate sidechains. How to run a sidechain with the Mantis network and roll that over into production code...

And then choosing your own UTXO and some other things that exchanges have requested.

And that's that's mostly meant for the PHD's and people who care about that stuff and then the other track is going to be for developers. People who are interested in writing Plutus smart contracts and people interested in this extended UTXO model, as well as how does Pascal, Plutus, and Marlowe, How do they all fit together and what does that development experience look like.

The advantage of that is we could take the Haskell wallet backend that's built on verified formal code. Really, really good Haskell code and connect it to the rest client and then the rest client could have API compatibility or you could actually take that with some modification and potentially connect it to a Bitcoin wallet or you know, a Monero wallet or whatever that has UTXO accounting system, that's parametrizable and also it means that the lower back end can then have an independent release cycle to everything else.

Building manual transactions and offline transactions and extending that API for other parameters like delegation and so forth. We can do that without being on the normal release cycle for for Cardano. So those are going to be near term goals. That we're working towards me and meantime we have three parallel teams working full time on all of the Shelley related stuff, some on delegation, some on Ouroboros Genesis. Other dimensions of that stuff and some on the new Ledger rules You know some on how we're going to extend the UTXO set to include Plutus and Marlowe. It's a humongous amount of work.

The next versions will be on Ouroboros BFT and decoupling of components in preparation for Shelley. And then Shelley testnet next. And then after that, it's basically Shelley. Decentralization. Then very short leader after tackle on the side chains, extended UTXO and yeah, Plutus, Marlowe and then K-EVM and IELE. So lot of stuff is coming soon and long long overdo.

We built the the first formal spec for UTXO wallet.

SL to B we have this notion of taking the UTXO model and extending the UTXO model, so we can support Pluto styles from our.

And kind of the utility side of allowing smart contracts in some form in a functional form at the base layer with Monroe and Plutus and the extended UTXO model or if it really ought to be outsourced to a different Ledger that's meant specifically for safe contracts.

Bitcoin only covers a small sliver of it, and that's one of the original biggest frustrations that I had and others had with Bitcoin was It only covered a sliver of this beautiful, rich financial ecosystem. So what we decided to do is say, all right, why don't we build an accounting ledger that allows you to represent the types of assets and those types of transactions in the most efficient and parallelizable way possible? 00:20:29 So, you can get these to scale long-term performance, but then you can also do everything that Wall Street is used to doing. So, we created a domain-specific language called Marlowe. We also created a general-purpose programming language that was functional that Marlowe embeds in called Plutus, and we really rigorously thought about the UTXO accounting model. We also came up with a method to issue assets within that model that's interoperable with the Ethereum-style account.

And we're glad to see that there is still some innovation there. We still do learn from ideas that Blockstream has presented. Russell O'Connor's work on simplicity, for example, was very elegant and really helped us think through some ideas about Plutus. We would hope that the Bitcoin core developers take some of our work more seriously, in particular, work on sidechains, and in particular our work on UTXO wallet design.

Some of these can be done in parallel. Some of them require some sequential work, some is incredibly difficult research, other is just an engineering problem where we have to think carefully, like with the UTXO wallet about how we want to do it and why we're doing that and so forth. So that's what's going to happen. We're still going to be around and we're going to be asking for additional funding, but you get to decide whether. Let's see here. A lot of good and interesting questions.

Second, did he even bother to take a look at the other things that we've done, like, for example, does he know how to build a UTXO wallet? Well, he forked Bitcoin. Satoshi came up with that. Did he? Well, we didn't know how to build one. So we figured it out. And we wrote a formal specification for those things.