Charles Hoskinson, CEO of IOHK, went live yesterday and shared some thoughts on the Shelley release and upcoming new features that are anticipated for Q1 2019. He also touched on some issues that users may have faced following the latest Cardano 1.4 release.

Cardano 1.4 Release & Known Issues

Cardano 1.4 was released this week and many users have already downloaded the updated Daedalus

It is important to mention that 1.4 requires users to restore into the data layer of the system

This new release also takes the current way that we files were stored (where every block had its own file) and compresses them down to basically an epoch package

These 2 processes are I/O intensive

Note that users won’t have to redownload the blockchain and won’t have to be connected to fast internet for this to work

However, since it requires you to restore into the new data layer and clean up your hard drive, it can take quite a bit of time

Restoration time can be hours to days (especially if you have a mechanical, non SSD hard drive)

Most users should be able to complete this process between 30 minutes to 2 hours

Another factor which may be slowing down the processing time are anti-virus softwares

If the AV sees something taking a huge amount of I/O or moving lots of files around, it will get flagged as suspicious and the AV will analyze this against known signatures and bad patterns

And even if the anti-virus software deems this activity as being okay, the active analysis can slow down the time it takes for the new Daedalus to install

To counter this, disable your anti-virus temporarily during the installation and restoration process, then re-enable it once the process is over

Another thing to note is that you won’t instantaneously see a reduction in storage size as soon as the installation is complete

This will be a background process that runs once the restoration is done, which gradually cleans up the files

Depending on the system you are using, you are looking at possibly a factor of 10 in reduction of the amount of storage on disk!

Unfortunately, it is a long process but this is a big update to move away from the old data layer. And this is not an event that will happen everything there is an update.

If you have Issues with the Update

If you have other issues not mentioned here, please check out this forum post with some of the Cardano 1.4 known issues or post in the Community Tech Support category of the Forum (please search your issue first, it might already be an existing thread! )

) If you have Telegram, we also have a Community Tech Support channel.

And finally, if you still can’t resolve your issue, please contact IOHK Support through their Help Desk.

Shelley Release

To describe the Shelley release, Charles broke it down into 3 dimensions: Testing Deployment Social



Shelley - Testing

With Shelley, IOHK have constructed a family of new protocols (for example: then network protocol, Ouroboros Genesis, the delegation scheme and the incentives scheme; this is all alongside the concept of stake pools and all the logic behind them)

These new protocols have to be fully implemented and require time to verify that they are correct

IOHK have written prototypes for these so by the first half of Q1, it will be about getting to a point where testing can begin to verify that ideas match reality

The good news is that the code quality is high and the engineering is good

The team also de-risked it by having 2 competing teams trying to do the same thing, using different tools, techniques and processes

There was the pragmatic “Silicon Valley style” Rust team as well as the disciplined, specification driven Haskell team

Both teams are working towards getting these protocols implemented and tested

Shelley - Social Aspects

Once we’re ready for a testnet, we will need to build a large population of stake pools

Out of curiosity, IOHK ran a registration earlier this year to see how many people would be interested

They received interest from over 4,000 people

In January, IOHK will reopen the registration and try to get as many people interested, potentially running a stake pool and rolling them over to a testnet

IOHK hopes to try to get as close to the number 1,000 as we can and wants to get 2-way feedback going on the protocol

It is not good enough to just have all the code written and protocols ready to go and tested

It is a social component as well

IOHK will need to meet a certain critical threshold of people who are actually deploying and running stake pools and understanding what that means for Shelley to be successful

Shelley - Deployment & Upgrade

For the actual roll over from what we have today (Byron) to where we would like to go (Shelley), it will require a series of updates to the Cardano client

At least two updates will be required: from Ouroboros Classic to Ouroboros BFT (this will be Cardano 1.5) from Ouroboros BFT to Ouroboros Genesis

The current implementation of Ouroboros Classic is very old and based on ideas that IOHK had back in 2017

It has evolved quite a bit since then and the design of the protocol (between Genesis and Classic) are very different

This means there is going to have to be a “fork” to get us to Genesis

For this, IOHK have decided to use the ‘halfway house’ solution

They will implement Ouroboros BFT and bring that in at the base level and fork to that, then a migration path from BFT to Genesis will occur

BFT will be the the last piece of code that IOHK will be committing to the legacy Byron repo

Once implementation of BFT is done and we have begun broad scale testing of it (both on Rust and Haskell), there will be a series of upgrades to get us to Shelley

There will be changes to ledger rules, API’s, network stack and all are required for Shelley logic

There have also been considerable improvements made to the release process, QA process as well as the ongoing work with the new code bases that have little technical debt and are based on good design principles and good engineering practices

One of the reasons IOHK and Cardano had so much trouble throughout 2018 was that they were dealing with a code base that did not have good documentation, was laden with a lot of technical debt and where the original engineers who wrote the code base were no longer with the team

If you look at the progression of updates from 1.1 to 1.2 to 1.3, you can see that it has been mostly accomplished in cleaning this up to the extent that IOHK completely rewrote the entire wallet logic and refactored the core

All the work has been done now and the new system will not have any of these legacy concerns

It will be much simpler and easier to test and understand

Also to note with deployment is that we will likely have a gradual winnowing of federated control to decentralized control

Epoch by epoch, more of the slots will be made by stake pools and less by Ouroboros BFT

Until eventually, that will disintegrate and 100% of the slots will be made by stake pools that are following the protocol

Other Features

Now that we have a decoupled wallet backend come January, it means that we can start augmenting and taking the wallet layer to the next level

If you take a look at the Rust client, you can note that you can do cool functions like manually constructing transactions, signing offline transcations and manually selecting UTxO

There is also the additional idea of a wallet scriptlet

This is a small script that you can write like a shell script or like a python script that automates the wallet process (You can do this with the Rust client, not currently with Haskell client.)

A big priority in Q1 for the Daedalus team will be to put a terminal into Daedalus itself, which allow you to interact with the wallet layer through that terminal. This will also enable an advanced user mode with the features listed above in addition to running your own scripts inside the system

Communication Feedback

IOHK will also start writing content about what the delegation center is going to look like, what the delegation process will be and also the presentation of things like stake pools

This is a controversial topic because like the Google Play Store or other app stores, the one who controls what you see first is usually the page that wins out

If you are on a subsequent page or less prominent area of the GUI, you will have a significantly lower percentage chance of getting eyeballs, attention and interaction by users

It is very important that we discuss this with the community about what the optimal way of displaying available delegation pools and how those mechanics will work

It will be necessary to get communication feedback on the different ways we can do this and to eventually converge on a design that is fair for people

We are now at a time where we are moving from hardcore mathematics and protocol design into opinion and what is fair, and this new phase has to be socialized and go beyond our best guess

Ledger support

On the new data layer, we are going to have Icarus-style addresses (which Ledger supports)

Through Emurgo, we have begun discussions with a firm called Vacuum Labs

Vacuum Labs have completed an analysis of where the current Ledger code was at and come up with upgrade plan to take that base and make it compatible with our system

They have proposed about 5-6 weeks of engineering work, starting in early Jan

Once this work is done, it should give us the ability to easily interact with Ledger

For Daedalus, the earliest we could potentially see this is February

It might be earlier for the Yoroi Wallet

Yoroi is also working on Trezor support

You will also notice that once Icarus-style addresses are supported by Daedalus, there will be another transition where IOHK would like to get people away from the old, non-deterministic addresses to new Icarus addresses

This transition will result in significantly faster recovery time for restoration, easier addresses to work with and an overall better experience for people

Furthermore, Yoroi and Daedalus should be able to restore from each other at some point

Other Wallet Updates

Charles also talks about how IOHK will start building for an offline center that can segregate your hot wallets from your cold wallets

Currently, we already have paper wallets and will soon have Ledger support

Functionally, this means that Daedalus needs to account for 2 different types of wallets in the system

Right now, we have one type of wallet and users can create as many different accounts within that one wallet class (each one being an HD wallet)

At some point, we will have paper wallet, Ledger wallets and your regular hot wallet

It will be necessary to segregate because of the concept of cold staking

With cold staking, we want to be able to control the stake, for the purposes of staking, delegating and voting, but do not want to take the private keys and expose them to a hot wallet

Therefore, there needs to be a way from a GUI to see what your balance is on that device and to have a process of importing a transaction that can give that stake key authorization

This should be converging mid-January to February

It is actually an easy to do these things but there needs to be a few more things in Daedalus to make it happen

Charles adds that the good news is that it uses an easy-to-understand GUI approach (react polymorph) built on top of chromium and node

As a consequence, the team can do rapid prototyping and iterations

Usability

In this portion of the video, Charles talks about his excitement on the prospect of actually making Cardano a good user experience

The problem has always been that people have entered into Cardano with unrealistic expectations

These being that Cardano and Daedalus are consumer products that are completely polished and finished like Windows 10 or the latest macOS

When Cardano was released in 2017, it was very early product and also a huge learning experience for our users and ourselves

If you have ever used beta or version 1 software of something using new techniques, it is a reality that there will be bugs, frustrations and unexpected crashes

Though we empathize and understand that people have had issues or things are slower than they should be, these are growing pains

You will have noticed that over the course of this year, we have made massive improvements to the system: the network stack has gotten 3 to 4 times faster on average memory consumption for Daedalus has gone down by 75% or more disk storage has gone from multi-gigabytes to hundreds of megabytes or 1-2 gigabytes massive improvement in UTxO selection, where now we have a system that won’t fragment and once we move to deterministic addresses, we will have paths to enable quick recoveries and in a short amount of time, IOHK also built a great user experience with Chrome as a reference project, which led into the Yoroi project at Emurgo

Cardano is a beta product, and we are all working hard to make it better

It is important to point out that we have not had massive or significant bugs that caused huge amounts of money to be lost or for the network to go down for weeks at a time

We have also provided multi-platform support through Windows, Mac and now Linux

Moving into 2019, IOHK feels it is now worthwhile to have a dedicated Product Experience Officer

This role will be to start with user experience and work backwards to what we need to do to enhance the protocol and technology to massively improve things like usability, start up time, UI and UX

It was not reasonable in the first year because there was still a huge amount of learning with QA, help desks, release cycles, dealing with exchanges and users, etc.

But now we have proper processes and are in a position where such a role makes sense

Client Segregation

Charles quickly adds in here that not everybody needs to have full client

When Cardano was first launched, it made sense to build up a large node population of full nodes

This was so that when full peer-to-peer or full network switches on, there will be a resilient backbone of full nodes

But at some point, we do need to see client segregation

This means on the light-client and mobile side

In 2019, we should expect to see a natural settling of people preserving those nodes as well as people who prefer to switch to lighter experiences and others to cellphones

In Conclusion

This was a productive year, a lot was learned

Moving forward, there are lots of workshops, socialization, new features coming

IOHK will make the best effort to deliver in Q1 in 2019, unless there is an unforeseen significant delay

As always, the goal is to get updates and releases out when we can, but to to also release them with reasonability quality, good user experience and high probability of success

It is incredibly important to understand that when Shelley comes out, Cardano will basically be on the same footing with every other major cryptocurrency in the space and that it will be fully decentralized

It will, in fact, be 50 to 100% more decentralized than Ethereum, Bitcoin and EOS in terms of control dynamics

This is a big deal and if you don’t have the right social structures in place for that, it will not be successful

That’s why we’re excited of what’s to come. With Cardano Foundation back and operating and able to begin investing money in the community and what our ecosystem cares about, IOHK’s progress will be met in tandem with great community development

Finally to note, we have seen good initiatives in the community space like The Cardano Effect Podcast

Charles adds that it would be wonderful to see other similar podcasts start up in other languages and over time, community activity like this will stabilize and become the norm

Thanks for reading Happy Holidays everyone!