In the latest video from Charles Hoskinson, CEO of IOHK, you can listen to updates on the Cardano project and its various workstreams that he provides:
Here’s a summary of this update video:
Cardano 1.3 is currently in QA. It has passed the first QA cycle and if it keeps up the current rate and major problems are not detected during QA and integration testing, they are looking at an early August release for both Daedalus and Cardano.
This version of Cardano carries network enhancements, code refactoring, and enhancements to Daedalus itself. The underlying code and memory utilization is being refined considerably. This means an approximate 5x reduction in memory usage. Internal benchmarks went from 1.2 GB to 200 MB on the Mac client.
IOHK is working in a joint partnership with another company and come August 15th, there will be an announcement that everyone will be excited about. This wallet will be complementary to Daedalus and will have cool and interesting features! It also has a nice roadmap. So look out for that mid-August…
IELE Test Net
Right now, they are on target to release the IELE testnet in late July. This is exciting because it will be the first time that you will be able to write smart contracts using something other than the EVM. You will be able to use Solidity, and IELE code itself. Support for IELE in Remix has been added. There will also be a lot of custom assets with respect to this launch. Videos and tutorials will be provided. The hope is that you will all use the IELE testnet and let IOHK know what you think about it!
The already released KEVM testnet has been very successful. They have received great advice and suggestions to make it more developer-friendly. A new product manager, Marc, has been brought on. He will be thinking about developer experience: STK’s, frameworks, etc to make Cardano the best platform to develop on.
They are making a surge on the QA side. Their hope is to automate things that are currently being done manually. IOHK is working with 2 firms (Allied Testing and QuviQ) on this and have learned quite a bit through them.
Moving into September and October, Cardano 1.4 is on the horizon. 1.4 will probably be one of the largest updates to Cardano since they have started doing updates. This will include the Cardano wallet backend, which they have been working on since February. Back in February, IOHK had learned enough about how UTxO-style wallets work to go ahead and write a completely new specification and rigorously improve properties. Read this guest blog post by Edsko de Vries, a consultant from Well-Typed, on how IOHK does input selection and other things that are a direct result of that project that started in February.
April is when the specification was finished and at which point, it moved into the implementation side. Six engineers have been working really hard on this and sometime in September, they hope to push this into the QA process. And after that process, Cardano 1.4 will be ready to be released.
In addition to that, there is a team of people working on the core of Cardano. They are working on making it more modular, easier to write tests against, and preparing the infrastructure work for putting in the Shelley-specific code (which is for decentralization). There is still another 4-6 weeks of refactoring to do and that will bring them to a good position to start building and enhancing the core and increasing the reliability. A lot of this work will end up in 1.4 as well.
For the everyday user, Cardano 1.4 won’t provide significant speed-ups or performance enhancements. While exchanges with lots of addresses and many transactions in and out, operating in scale, will notice the improvements.
Additionally, they are also gradually moving Daedalus over to v1 API’s that were released in Cardano 1.2. There are 19 of them that are specified. Daedalus actually uses 26 API’s in total. IOHK is starting the process to connect to those API’s and trying to decide whether to extend the v1 API’s to cover all of Daedalus or to use another method to do that.
Charles adds here that the V1 API’s are very good. If you are an exchange or a project building on top of Cardano, he highly recommends you to have a look at them.
In terms of specification work, sometime this month, the delegation specification should be finished and will be sent over to be implemented. Also, the incentives workstream is conceptually done. They have a good idea of what they want the first version of Shelley’s incentives to look like. But there are still lots of questions on the network side of things and it is still in deep design. But they have good concepts that they are slowly pulling in to get everything they need for Ouroboros and decentralization.
IOHK is gradually scaling up the team that is working on Ouroboros Genesis. This team is looking at what a prototype looks like. This means looking at not just the implementation of the protocol in Cardano, but also creating a stand-alone prototype to implement into other projects. They have had discussions with a diverse group of people who are interested in Ouroboros, prominently, members from the Hyperledger group who are curious of what Ouroboros can do for projects like Fabric. At the moment, they are trying to figure out if it makes sense for them and for us. It’s a pretty nice protocol and a lot of people seem to like it.
Unfortunately however, Ouroboros is a bit hard to explain and right now, it is living in the world of cryptography and high science. What needs to be done is for it to be pulled into the engineering world and to be made far more understandable. The benchmark in terms of pedagogy with that respect is the protocol called Raft. Raft is created by John Ousterhout and Diego Ongaro over at Stanford. Purpose of Raft is to be a protocol that does everything Paxos does, but much easier to explain. So, IOHK is looking at how to explain protocols, and their hope is to apply the same techniques so that it is easier to understand how Ouroboros works under the hood and how it solves certain classes of problems like nothing-at-stake and long range attacks. This will be a big project for IOHK research.
Plutus & Marlowe
After Cardano 1.4, Plutus and Marlowe development has been scaled. The team has gone up from 2 people to 6 and hoping to be brought up to 8 people. The design of Plutus is actually starting to stabilize so now there are discussions of Plutus as a smart contract language and how Plutus will interact with the outside world and how to embed Haskell, etc. Throughout the summer and fall, this team will be working hard with hopes to pull Plutus and Marlowe as soon as they can. They will also work to combine with their Chimeric Assets standard that they have developed for issuing assets in Cardano, enabling them to make it into a multi-token ledger. There will be dedicated content for that. Hard to say exactly when this will come out since there are still some debates on a few final things on design. But the good news is that team has grown considerably and filled with remarkable people such as Phil Wadler.
Semantics Based Compilation
K is being rewritten in Haskell and Charles notes that he has seen great progress with semantics based compilation. They have started to test SBC concepts with functional languages, not just imperative languages. He recently went over to University of Illinois Urbana-Champaign and spent a week with the Runtime Verification team. He had a look at their demos and they were able to run an ERC-20 token on IELE. There was a lot of conversation about where SBC is going. The progression and results there are quite encouraging which is great since this was a high risk-high return project. Throughout this year, they will keep hammering on and pushing the envelope to get it done.
Twitter Question on Peer Review
Charles gets asked many questions on Twitter and one question was raised by user belowsearcher on whether they are ever going to publicize the peer-review content that IOHK gets when they submit papers to conferences. Charles wanted to answer this beyond a 140-character Twitter reply.
For those who aren’t familiar with the peer-review process in the computer science world, you generally submit papers to conferences. Within these conferences, there are different tiers. For example in the cryptography world, there’s Crypto and EuroCrypto. In tier 2, there are conferences like Financial Crypto and AsiaCrypt. Tier 3 contains conferences that tend to be a bit easier to get into and meant for papers that aren’t quite ready for prime time but are very promising. For top tier conferences, the acceptance rate for papers that survive peer review is roughly around 10-15%. They get a lot of papers from prestigious researchers and universities.
How that process works is that you actually submit the papers blind and the reviewers are also blind. It’s a double blind process. They don’t know who wrote the paper and you don’t know who’s reviewing the paper. But you know the reviewers are selected from a reviewing committee associated with the conference. Those reviewers have options from “strongly accept” to “strongly reject” plus a spectrum of decisions in between so they’ll write comments and provide an initial decision. Then you’re given an opportunity to write a rebuttal and they can change their mind from this or you get another reviewer. Finally, the reviewers will take the collection of papers that have been reviewed and decide which ones are worthy of being presented at the conference.
Those comments and that back-and-forth are generally not publicized. This is because it gives the reviewers and the paper authors the freedom to be a bit more honest and less diplomatic in the ways they present things. If it was made public, they would need to be more conservative in how they present things and so forth. That said, the conferences themselves are public affairs to those who register and the presentations and dialogues there are also public. It is a fair compromise of what’s necessary to get honest dialogue and what’s necessary for transparency to the academic community.
For Ouroboros Genesis and Praos, IOHK presented these at Euro Crypt and there was quite a lively, public discussion. Whereas the peer review process for it was private. This is just a standard for the entire space and for the academic community as a whole. To answer the Twitter question, Charles and IOHK will not be publishing those comments, as it will be counterproductive. The reality is that these protocols are meant to be used and therefore, will escape the academic world and enter the world of engineering. Charles says here that “to be honest, academic papers are less interesting to the engineers because you have to start talking about things other than security but usability, practicality and usefulness according to a particular domain.” Protocols are not universal and ubiquitous nor are they useful for everything - reality is that they are a tool like a hammer or screwdriver. As a consequence, not every tool is meant for every job. You need to think about things like privacy, level of centralization, performance requirements, how resilient you want the protocol to be to failure, deployment scenarios (ie. Will it be run by a small or large group of people?, Are they geographically clustered or all over the world?, Are these nodes intermittent or online 24/7?) These factors drive which protocol is more meaningful. IOHK’s hope is, as a community and as a space, to start having a broader conversation about such things because what has been observed unfortunately is that there are financial incentives for people to make very bold claims about the things they build and their engineering approaches.
For example, they’ll say things like five hundred thousand transactions per second can be achieved or you can move blocks around in 500 milliseconds. Unfortunately, that’s probably not true in almost every scenario and even if it is true, it will only be true for a very particular, very specialized type of deployment and use. In real life settings, especially for cryptocurrencies, you would seldom see numbers and performance like that. Even if you did, you’d have to give up something very significant. We will make a bigger effort moving into the future to have broader discussions about trade-offs and about utility and usefulness and what security assumptions you’re making and who you are putting in control when you launch these protocols.
Moving into 2019, IOHK is keen to start layering protocols with new capabilities. In particular, in the Bitcoin space, there is big discussion about using things like Lightning. There is a lot of merit and good ideas about hybridizing a base protocol that is slow, highly secure and very decentralized with much more performant-federated protocols that can be used for certain use cases (ie. for micro-transactions or connecting on federated actors like banks or financial institutions). It does make a lot of sense to think about that model in order to get the best of both worlds.
To this end, IOHK have started looking into second layer protocols that they think over the next year or two can be gradually pulled into Cardano. This includes temporary protocols (things that you do for a short period of time) like for example the Kaleidoscope and Royale research streams out of Tokyo Tech. These are for things like card games and broader computations like decentralized exchanges to things like making our transaction systems faster through methods such as payment channels. They are also particularly interested to see if you can use trusted hardware for that. So this will be a big agenda moving into 2019. Something that IOHK thinks is under-appreciated right now in the smart contract space.
The good news here is that Ouroboros is a tremendously good protocol for these layer 2 style solutions. Because of the slot leader design, it maps very nicely into that architecture. There are cool things that can be done there and will surely add value to the ecosystem.
Cardano is coming along quite nicely. Everyone is happy with the workflows. More consistency and reliability on the dates for projects have been observed. The code and engineering quality has gone up enormously. IOHK has also found easier ways to work with a lot of partners.
Many people don’t know this but IOHK is one of many engineering companies actually working on Cardano. On the auditing side, there is FP Complete. On the development side, there is IOHK, Tweag, Well-Typed, Predictable Network Solutions, Allied Testing, QuviQ and other small consultancies that are doing various little things. They all have a role. And because they are geographically dispersed, it took some time to figure out how to manage all of that and to get predictability. With inter-dependencies, if one group is delayed, it delays everyone but they have gotten better at handling this. Charles says he is excited to see the second half of this year materialize and is excited to see 2019. 2019 will be our year and they will be able to get onto sharding and blockchain based governance.
Another thing to mention, Charles brings up wallet diversity and their interest in it. At the moment, the protocol is still going thru active research, and it would be counterproductive to have lots of competing implementations. This is because when you finally come to a solution, there will be a huge coordination cost that will dramatically slow down the ecosystem.
For the sake of resilience and decentralization , it is important that wallet diversity occur. IOHK is actively moving towards that. At the heart of diversity is specification. Their first specification that was released was the wallet backend and you will see specifications for core, for network and other components for the protocol. These are implementation independent. Any developer with a reasonable set of skills should be able to build a wallet, and this would be in any programming language they so choose. IOHK have begun an effort to start constructing in parallel a full node of Cardano in Rust. You will notice this in their Github repo. They are scaling this up and hope to find a partner to maintain that Rust client after it gets to a reasonable level of maturity.
There are some good ideas on how to do this. If one looks at the Linux Foundation and how the HyperLedger project is governed, there is quite a bit of merit in that structure. But also this approach is sometimes bureaucratic and not as inclusive as it needs to be. Moving forward this will be one of their challenges, one that is less technologically challenging but more of social, coordination and control-based.
Charles closes off by saying it is nice to see Cardano maturing as a product. There are exciting things coming like Ledger support that is expected to come with Cardano 1.4, and afterwards, multi-signatures.
They are getting into that backbone and Cardano is looking more and more like what people tend to expect when they think of a cryptocurrency. The advantage here is that the core is very different – much better built, more secure, constructed with peer review, and built with a lot of brilliant people who truly care about the protocol. These people are coming up with better ideas than the ones they’ve seen in the space. The input selection policy in particular is something that probably should have been done a long time ago, so it’s nice to see something like that developed.
Finally, thanks to everyone for their passion and support in the project!