 Hi everybody, this is Charles Hoskinson, broadcasting live from Zurich, Switzerland. I just got off a plane and this is my first attempt at doing a video like this, but I decided I'd give it a shot and experiment. That's what we always do with Cardano and the IWG ecosystem is we like to try out new things. So the purpose of this video is to discuss briefly a few things about Cardano, where we're currently at, where we're going and just provide the community an update on some things that we're thinking about. Okay, so the most pressing collection of questions stems currently around certain technical issues like, for example, slow recovery speed, connecting to the network issues, when things are coming, for example, when are we going to get a Linux client, when are we going to get a paper wallet generator, when will multi-sig come, and so forth. And so most of these come under the I'd like to use the product and I'd like to use the product as safely as possible. That includes ledger integration. Okay, so what's the story there? So when we released the client Byron back in late September of 2017, there were a few goals that we had. Number one, due to the nature of how ADA was sold, the buyers had to redeem vouchers to get their ADA. So it was a high priority that the buyers redeem into the system. This is more than 80% of the ADA in circulation. So to us, it was very important that that group understand how to install dead lists, use dead lists, redeem their vouchers, and learn how to safely use exchanges so they can have liquidity if they so choose. And then ADA could also get more broadly distributed from the initial distribution. So we did a help desk tour in October and we invested a lot of time and effort into education, and particularly in Asia, trying to get people onboarded and into the ecosystem. Two, we had never deployed a product before to an exchange customer. So we had quite a bit of experience dreaming of what appear to appear protocol needs to look like and other such things. But exchanges have different needs. They use wallets in a very fundamentally different way. And unfortunately, we weren't able to collect a huge amount of business requirements prior to the launch of the system. So we launched with fewer exchanges instead of lots of exchanges so that we could consider this to be a multi-month beta test where we could learn how exchanges use wallets and begin creating some special optimizations specifically for them, in particular, Binance and Bitrix. As many people have noticed, both Bitrix and Binance have had some issues where the wallets have gone down. And that's a direct consequence of our software not being where it needs to be with respect to exchange users. Now, we set up a 24-7 support line with them. And every time issues occur, we work very carefully with these exchanges to resolve those issues. And so far, we've done a pretty good job. Unfortunately, something broke and Binance also requested some changes right around the turn of the year. So during Christmas time in New Year's Eve, when most of our personnel were on vacation, the wallet needed some maintenance. So a skeleton crew decided to forego their vacation and actually worked very hard at creating a patch to repair what was needed to be repaired. Now, this was a process because you can't just write code. You have to run code through QA and then even after you've created a patch, it takes two to tango. So the patch had to be shipped to both Bitrix and to Binance. My understanding is that Bitrix is fully operational again and that QA and patches have been approved and are working properly. With respect to Binance, they've requested a new API, namely batch processing of transactions. And our engineers are currently working on this amongst other things and our hope is very shortly to be able to get everything there back online. But overall, the lesson has been great. We've collected enormous amounts of data from the use of these nodes, including network traffic and how they do withdrawals, how they do deposits. Every exchange is a snowflake, but it's greatly informed our engineering efforts. And we've decided to create a dedicated work stream and assign dedicated personnel specifically to improving that experience for exchanges. Okay, so what's next? Where are we going? There's January and February and many months coming and then there's the Shelley release. So the immediate priority is that there is some technical debt in our architecture in our code from the Byron release. And we've been working towards reducing that debt in parallel to finishing the specifications for Shelley and starting new code work for Shelley. So what we've decided to do is enhance our resources and work very carefully at accelerating the technical debt reduction. So our goal is to get most of that technical debt in the architecture completely removed by the end of February with the hope of shipping a patch that will dramatically improve things for some users by early February and a follow up patch sometime in early March that will continue those improvements. And we're going to leave a dedicated team to do technical debt reduction for the Byron code base. This will not interfere with the shipping of Shelley, we hope. And we're going to bring a new company on board specifically to accelerate things so that we can leave key core personnel in the Shelley work streams and continue our march towards launching Shelley. So as a user in the coming weeks expect to see a patch issued to the edge nodes probably early February is our hope. In addition, we are beginning preparations for the first Shelley test that. Now our hope is to launch that Shelley test that sometime in early February to mid February. This could be done sooner or later. It just depends on a variety of factors on the DevOps side. And we're working real hard at getting that out as quickly as possible. Now, once we do some API rewrites, once we do a technical debt reduction, it's going to become very easy for us to then deploy new features in a rather systematic way. In the feature pipeline that I prioritize, I prioritize the safe storage of ADA as the highest priority of features for the moment. And that includes cold storage options such as cold wallets. So like paper wallets and hardware wallets as well. And that also includes multi six support for Daedalus. The only caveat to this is that for ledger, the hardware wallet partner we have, we're working with a third party firm named meta layer. So while we have control over some of the development process and progress, ultimately there's code that has to be done on the ledger side and through meta layer. And so we can't make a firm guarantee that that's going to ship at a certain date because we can't promise for third party contractors when they're going to finish things and how they're going to prioritize things. But we've told them that this is a very high priority. It's something that the community desires. And we're going to work real, real hard at trying to get that out as soon as we can because we understand there's a very strong community demand. In addition, once we've reduced the technical debt, we've redone some of the remedial work and cleaned up the APIs a bit. Our hope is then to onboard a much larger set of exchanges. It would be problematic to do so now because of the unique support nature of where we're at. But our hope is towards the end of the month that this work will be concluded for the exchange work stream, in which case we have several exchanges waiting in queue that would like to list data. And we can work with them directly to get that done as quickly as possible. So that's one of our goals. Okay, now there's a few other things in the house cleaning section that we'd like to resolve. For example, easy submission of logs is something that slipped the Byron release. It was something I really wanted to get in but unfortunately software is software and occasionally you have to cut it somewhere. So what we decided to do was to cut some sort of easy submission to log and put it for a later release. So my hope is to get that feature out sometime in February. What it basically entails is something in the GUI of Daedalus that will allow you to submit logs directly to us without having to go through the Daedalus wallet.io slash FAQ process that we're currently using. The purpose of this is we would really like to get a better understanding of how and where our users' clients are failing. At the moment, we are requesting everybody who has an issue send us their logs and we try to work with people. Unfortunately, the vast majority of users who are experiencing issues for whatever reason, either competency or time, have not decided to send us logs. In particular with the connecting to network issue that has cropped up for a minority of our users, this is becoming somewhat problematic. We have some ideas on what could be causing these issues and we have some ideas on how to resolve these issues, but these are hypotheses until we actually get logs and we can hunt down these things. So we're left with a guessing game where we can clean up some code and make some changes, we can go patch and see if that resolves the problem, but we don't actually know 100% if it's going to resolve the problem until we see the user logs. So our hope is to make as soon as we can it as easy as possible to submit logs to us. In the meantime, if you are experiencing an issue, please, please, please submit logs to us because it will allow us to resolve those issues more quickly and also have a higher degree of certainty that they actually have been fixed. There are a few things I'm not happy about. I'm not happy about how long it takes to recover the wallet. The reason being is that it does an entire traversal of the blockchain to recover all the history of the wallet from the very beginning. There are many ways to optimize this and improve the user experience and we've made this a priority for all the users who have been using the dead list wallet when they enter recovery mode with the seed think that the wallet has frozen and it actually hasn't frozen. It's just taking quite a bit of time to recover because it's doing a full blockchain traversal and then they shut the wallet down. It stays in recovery mode and it causes all kinds of havoc. So we'd like to speed that up a bit so that the user experience is much better. So that's in the house cleaning department. So there's a few other things that we're working on under the hood to try to make the dead list experience better. A few other things we're working on to make the code much more concise and clean in certain areas that just didn't get where they needed to be during the Byron release and our hope is that in the coming weeks we're going to be able to chip away and hammer this until it's finally polished and finally made. Most of the IOHK team will actually be meeting up in Portugal, Lisbon this month and so we will have a giant in-person hackathon and this will definitely accelerate some things for us and we can definitely get some things done. Okay, so that's a brief update on some of the technical issues and some of the exchange issues. I am sorry that this has caused some pain and some sadness and I am sorry that there's been a lot of bugs that have caused some usability issues and not made it as optimal as it can be. We are aware of them and we are working really hard. The team has over 25 people working full time. There are project managers. We have meetings every single day and in many cases people have foregone their holiday vacations and time with family to be here for the ecosystem and work hard. As for other things like the Linux wallet, that's one of those things that we just have to make a lower priority until other things like technical debt for example have been reduced but it is something that I really would like to get out. We have a great Linux community. We actually use Linux as our development platform. We love NixOS and these things so it's a shame not to have that where it needs to be and so for me it's very important that we get it back to that. That's Byron and that's Byron for the next two months. Expect things to gradually get faxed there. Expect the connecting to network issues to start receding. Expect patches coming in February and in March which will dramatically improve things. Expect more exchanges coming and we're certainly going to work real hard. Now once the great cleanup is done, then the next step is to gradually roll out Shelly features. So there are many work streams for Shelly from delegation and stake pools to enhancements to the network. The highest priority is to begin the process of getting people who want to run stake pools into some sort of slack channel to inform that we can have a direct communication with them. So we can get a better understanding of what their technical competency is, what operational costs are going to be and required hardware is going to be for staking, these types of things. Our hope is to get between 25 to 100 stake pools by the launch of Shelly. So come February, probably early February, right around the time we ship that patch, we're going to open up a form on our Reddit and in the Cardano forums for people who want to register as a stake pool to give us all their details. And then on the back of that, we'll open up something in our slack channel at IOHK Slack and start a direct line of communication with these people so that we can begin that process. The final output of it will be things like the production of, for example, Docker images and things that can be deployed to Amazon EC2 and Rackspace and other servers for people who are running stake pools and eventually for people to deploy their stake pools in the Shelly testnet for the next iteration of testnet. Unlikely the one coming in February, but probably the one that's coming in March. There are a lot of little fine details that still have to be worked out. For example, we are considering creating a special type of address called exchange addresses which are removed from consensus. So exchanges will not have any influence over the staking of the system, but this does require some careful thought and consideration and a little extra work. And it was something that we didn't fully anticipate when we first spec the protocol out, but we have sufficient resources to accommodate these types of things. In addition to that, we also would like to support cold staking. So if you have a ledger wallet or paper wallet, you'll be able to assign a proxy key that you can control within Daedalus which is hot and live but can't spend the cash that's sitting on the cold wallet device. So you can stake or delegate your stake without needing to have your stake be live. This is a very requested feature from our users and it's something that we're pretty excited about being able to bring into the ecosystem. So in the coming months, these are the kinds of things that are very high priority for us. Network improvements will come iteratively and gradually. We have a dedicated team working on that, both IOHK and a firm called Well-Typed, as well as a firm called PNSOL. And we're doing everything from saying, how do we increase the level of decentralization in the network? How do we resolve some of the issues we've noticed with firewalls so that users can install Daedalus and it just works. They don't have to do any special configurations, these types of things, and also prove download time and these things. And that'll come iteratively and in a series of patches and a series of tests. It's a well understood problem. It's just one that takes time and it's one that takes testing. So those are some of the things that are on the immediate horizon. On the longer term horizon, we are working on the formal verification and specification of War of Wars prowess, which is the next generation of the War of Wars protocol. We're trying to make provisions to accelerate that work stream, but it is among the most technical and complex of all of our work streams involving the production of a new site calculus, as well as a lot of coding and languages like Isabelle. So the preliminary work has already been done. It's public. We have a repo. I believe it's IOHK or Boris spec on GitHub so people can follow along, but there's quite a bit more to do. The end result of this output will be the first formally verified and specified consensus algorithm in the cryptocurrency space actually used in a cryptocurrency. So that's pretty exciting and we probably will end up writing a paper concurrently with releasing the protocol because it's a novel from an academic viewpoint. But that's coming along quite nicely and we're going to try to accelerate it so we can get it out the first half of this year potentially, but it might bleed into the second half of the year, although it's not required for Shelley. In addition to that work stream, also we've gotten a lot of questions about smart contracts and when and how are we going to launch that? What is our strategy going to be for that? So as it stands right now, what we believe the best option is to take the Mantis client that we've constructed for Ethereum Classic and to make the virtual machine component of the Mantis client pluggable. So at the moment it's using the Ethereum virtual machine, but we can install Yella, which is Cardano's virtual machine into this framework and then deploy a test that so that we can begin testing Plutus and Solidity smart contracts on the Yella virtual machine so that we can do things like fine tune the gas model and also clean up a lot of the engineering rough edges since December. We're coordinating very closely with a firm named Runtime Verification on this and we're expanding our commercial relationship with Runtime Verification which will include a considerable expansion of their team. Currently they have eight people and our hope is to more than double the size of that team over an arc of a few months. And they have a very rigorous, beautiful work agenda for evolving Yella to make it the finest virtual machine the world's ever seen for smart contracts. So we're really excited, really proud of that and we'll make a dedicated announcement at some time soon about what our plans are. But because we're looking at pluggable consensus with an existing very mature Scala base code base this means that we probably can accelerate our test net plans for Gogan, our smart contract layer. So we'll make an announcement in early February about what that means but our hope is to get things sooner rather than later because a lot of people really do want to start writing some smart contracts and testing software and they're fairly excited about it. There's still a lot of work that would need to be done to link Cardano CL and SL together for example we have to finish some of our specification work for our proof of stake protocol so the sidechains connection point as well as some things about how we wish to handle merge staking and so forth and that's actually one of the reasons I'm here in Switzerland I'm attending a conference called Real World Crypto but it's also a great opportunity to meet up with all of our scientists and have a discussion about some of the final things that need to be done in that respect. So very exciting, a lot of research work streams are moving along our smart contract layers moving along quite well and we're pretty happy with the status of things and we're pretty happy with how things are working and the team is growing considerably we've been hiring like crazy we've onboarded four new Haskell developers just the last three weeks alone we intend on bringing on board about five new Scala developers within the next six weeks we've hired another DevOps person and we'll be hiring more DevOps people and we are partnering with some new companies and we'll be making those announcements at some point specifically to help us accelerate Cardano's progress so that we can continue the momentum that we've already achieved so that's my update thank you so much for listening I do appreciate it and my final thing is that I'd like to thank all the members of the community for their incredible patience I understand how difficult this is we live in a space that tends to measure things in terms of days and weeks and most of our competitors tend to deal with forked code so they don't start from scratch, they start from Bitcoin or they start from Ethereum or from NXT or from BitShares and they work their way from there which means a lot of things have already been solved for example people can connect to the network fairly reliably and the wallets tend to work so when you start from scratch you have to accept that you have to resolve some of the rougher edges but we believe in the vision, we believe in the roadmap and these are ephemeral concerns and they will be resolved and the team is quite good and the technology is good and the long-term output is that we have total control over the code base's long-term quality and the capabilities of that code so when we begin to do things like formal verification it's going to work very well for us and ensure that we don't have bugs and that the code is incredibly solid so we're paying a pretty hefty price on the front end and that price is jointly paid by you guys and by me and so I am sorry that it is taking time to get through it so please be patient I really appreciate your support and thank you so much for your time