The first Cardano smart contracts testnet launches today, the KEVM testnet, a correct by construction version of the Ethereum Virtual Machine (EVM) specified in the K framework. This technology, produced by Runtime Verification with the support of IOHK, is the first time that a complete formal semantics of the EVM have been produced. This is an important first in cryptocurrency that is a necessary step towards the promise of third-generation blockchains. A smart contract allows you to exchange something of value - money, property, shares - by means of a software protocol. The terms of exchange are agreed upon by the parties involved in the same way as a traditional contract, and the contract is executed automatically on the blockchain.

Developers will be able to take any application that runs on the EVM and execute it on the KEVM, which can also be used to rigorously prove that smart contracts work correctly. This is done by formally specifying a contract's desired properties in K, combining the contract with the KEVM specification, and then using the K framework to verify those properties.

Our second Cardano testnet to launch will be IELE, which is a new virtual machine for Cardano. IELE will be launched in July and is a register-based virtual machine similar to LLVM with an unbounded number of registers, that supports unbounded integers. With IELE, developers can write, compile and execute smart contracts, with improved security and performance compared to the KEVM testnet.

For now, we recommend that developers use the Solidity language on both testnets. However, the vision is that eventually smart contracts will be written in high-level languages that translate to IELE, such as new languages like Plutus (being developed by IOHK), but also existing languages such as Java or Python, and then IELE-to-IELE translators ensure the resulting code is optimal.

Cardano Testnets Website

K was developed by Runtime Verification in collaboration with Professor Grigore Rosu's Formal Systems Laboratory at the University of Illinois at Urbana-Champaign during the past 15 years, and incorporates the state of the art in language design, semantics and formal methods. Read more about the K framework in this blog from Prof Rosu, founder of Runtime Verification. A blog about formal verification and what this means for smart contracts will follow soon.

Smart contracts must be formally verified, so they run exactly as specified and are free from bugs or flaws. Only then can they be widely adopted as financial infrastructure that can be relied upon by billions of people.

We look forward to receiving your valuable feedback about using the testnets which will help us make Cardano best in class.

In the area of blockchain research proof of stake has long posed many questions for cryptographers and the subject has been of primary importance for IOHK researchers over the past two years. Professor Aggelos Kiayias, Chief Scientist at IOHK, has led work with a team of cryptographers to formalise a family of protocols called Ouroboros. It is a great distinction for their efforts that their paper describing the protocol was accepted to Crypto 2017, the foremost cryptographic event, and another paper was heard this month at sister event Eurocrypt. Eurocrypt is the flagship European conference of the main international community of cryptographers, the International Association for Cryptologic Research. About 370 delegates from countries worldwide arrived in Tel Aviv, Israel, to hear cutting edge research being presented from across the spectrum of cryptography. In all, there were about 70 presentations across four days.

This year, blockchain was more prominent than it had ever been at Eurocrypt. There were four papers presented during a dedicated blockchain morning session on the second day. The following day there was a talk on the 30-year history of cryptocurrencies, given by Matthew Green, a cryptographer at Johns Hopkins Information Security Institute. Three best papers were selected for an award at Eurocrypt, and one of them was on blockchain, Simple Proofs of Sequential Work by Bram Cohen and Krzysztof Pietrzak.

Academic interest in the area has nowhere near matched the rapid proliferation of blockchain projects during the past few years, and the increased focus of cryptographers at events like Eurocrypt brings a welcome professionalisation to the industry.

To be heard at the conference, papers must be submitted for consideration in a process called peer review. This notoriously tough sifting process can typically involve three or four people reviewing the paper, and it passing a programme committee of three dozen or more people, to ensure it makes a novel contribution to the scientific literature that advances computer science. Most papers are rejected. A double-blind admission procedure where both authors and reviewers are anonymous adds objectivity.

The novel feature of Ouroboros Praos is that it is the first proof-of-stake blockchain to be able to scale for widespread use and provide security against adaptive attackers. These are attackers that can instantly corrupt protocol participants, and the only restriction is that only a minority of the total stake can be in corrupted hands. A Distributed Denial of Service (DDoS) attack is a real-world example of such an instant attack.

Ouroboros Praos offers the same security guarantees as Bitcoin in that it can withstand attacks from stronger adversaries in harsh network conditions, such as where an attacker has some control over network delays affecting messages sent by all participants.

No other proof-of-stake protocol that has been peer reviewed at this level can provably offer this level of security guarantee under these conditions.

Peter Gaži, who presented: “Eurocrypt is one of the premier venues for presenting cryptoglogic research and it’s an honour for us to present our work here. The fact that we were invited serves as evidence the broader academic community is showing more interest in this topic.”

Aside from Peter and Aggelos, the other researchers on the Ouroboros team are Bernardo David, Alexander Russell, Roman Oliynykov, Christian Badertscher, and Vassilis Zikas. The previous Ouroboros paper, first in this line of research, is the first proof-of-stake protocol to be provably secure and peer reviewed at a leading cryptographic event. Ouroboros has a real-world implementation in Cardano, the top 10 cryptocurrency built by IOHK.

Cardano is a project that is unique in its vision, scope and design, and its world-class team is working at the frontier of computer science. As development progresses we're contacted on a daily basis by people from all around the world who want to learn more, and so IOHK was pleased to make its first trip to Germany recently to talk about Cardano. Dr Lars Brünjes and Dr Philipp Kant are senior members of the Cardano team and they were invited to the monthly Hamburg meetup Blockchain Mania last month to give a technical talk. Lars is Director of Education at IOHK and leads work on incentives, a key part of Cardano, while Philipp is Director of Formal Methods, the robust development approach that is the gold standard for IOHK development.

In the year since this Hamburg meetup launched its audience numbers have blossomed from 20 to well over 100 under the direction of founders Omri Erez, an android developer by background who now has a blockchain startup, and Kiriakos Krastillis, who is Head of Software Engineering at PwC Digispace in Hamburg. The crowd was keen and knowledgeable, including entrepreneurs and developers (and some Haskellers). They wanted a deep dive into technical aspects of Cardano, with a Q&A after each presentation.

Philipp took the audience through an introduction to Cardano, highlighting a few of the key features in development. Plutus and the IELE Virtual Machine are essential components of smart contracts, while sidechains will help the system scale. A treasury will secure future development by giving users a mechanism to decide upon and pay for changes. At the heart of Cardano is Ouroboros, the algorithm that underpins the Ada cryptocurrency. Developed by a team of researchers led by Professor Aggelos Kiayias of the University of Edinburgh, Ouroboros is the first proof-of-stake algorithm to be provably secure and was accepted to the leading cryptography conference, Crypto 2017. It is an efficient alternative to the energy-intensive proof-of-work protocol that underpins Bitcoin.

Producing excellent research is the first objective. The next is to take that cryptographic research, which is expressed in academic language, mathematical formulae and proofs, and turn it into another language – Haskell code that a computer can understand. Additionally, the research papers will not account for factors that arise during real-world operation, issues relating to databases or networking for example.

Turning the papers into machine-executable code is a lengthy and precise process, and one it is highly desirable to conduct carefully. IOHK is adopting formal methods in its development process to create software that is robust and reliable. This is an approach used in areas such as medicine and aerospace, where improperly implemented code could result in casualties. In the area of cryptocurrency, we've repeatedly seen flaws in code exploited and losses in the hundreds of millions of dollars.

The process of moving from paper to code is done in a series of small steps, rather than any big leap, Philipp explained.

The first step is transcribing the paper into an executable specification, and further steps refine this specification, adding all the necessary details.

Attention is paid to each design decision, and each step can be tested to make sure the code is correct. IOHK does this by using psi calculus. This is a family of process calculi that is a toolbox we are using to formulate Ouroboros Praos. We can embed psi calculus into Haskell, which allows us to run simulations and export code to a proof assistant such as Coq or Isabelle so proofs can be checked.

It is important that we have a good handle on the performance of the system. Before the launch of Cardano, Philipp oversaw benchmarking, tuning the parameters of the system to ensure it could perform well under various conditions. While this process is helpful to ensure the system is set up in a way that ensures stable operation, it is preferable to have a method for predicting the performance early on.

To achieve this, we use the Delta Q formalism, where each atomic operation carries is assigned a probability distribution for delay and failure. Those can be combined, either through simulation, or algebraically, to determine the expected overall performance of the system. Adding Delta Q annotations to the executable specification right at the start of the development process will show performance impacts of design decisions, and also provide a baseline for the benchmarks: instead of just measuring the performance, and trying optimisations to improve it, we can compare the results of benchmarks against a prediction, and tell whether we have a performance bug. If we additionally measure the Delta Q of individual parts of the program, we can even see which parts behave unexpectedly and should be optimised.

Philipp Kant (left) and Lars Brünjes (right) at the Hamburg event

Incentives are core to the design of Cardano and the related topic of staking has been one of the most keenly discussed among the community. Lars is leading work on Incentives, and the team includes Professor Aggelos Kiayias and Professor Elias Koutsoupias, at Edinburgh and Oxford universities respectively. Lars explained how well-designed incentives shepherd users through the system and encourage them to make choices that are not only in their best interests but lead to the smooth operation of the cryptocurrency as a whole.

In Cardano it is important that stake holders are online so they can be part of the election for who gets to create the next block in the blockchain, and to create that block if they win. The incentive for taking part in Cardano is Ada, as a reward for being part of the process and creating a block. By comparison, in Bitcoin's proof-of-work system, stakeholders compete to solve cryptographic puzzles, with one winner taking a reward for creating a block. However, in Cardano, users may not have the time to be online or take part in the election process, so they can delegate their stake to others who can do it for them. Those who do take part then pay a share of the reward back to the users who did not participate. Simply holding Ada gives you stake, and if you delegate your stake, you still retain the monetary value of Ada and can spend it as you wish.

Lars explained that about 80% of stake should be delegated to stake pools, that optimally number about 100. Stake pools must be online, and provide infrastructure for the network in the form of relay nodes. The leftover 20% of stake would belong to small stakeholders who either participate on their own or decide not to.

There are three types of address in staking, each associated with two cryptographic key pairs: one for payment, one for staking. A base address has a staking key linked directly to it; a pointer address links to a delegation certificate on the blockchain, and an enterprise address is for exchanges, who may not use the funds entrusted to them to stake.

Delegation of staking rights from one staking key to another is done by means of a delegation certificate, which can be published on the blockchain as part of the metadata of a transaction, in which case a pointer address can refer to it. Such a published certificate is called a heavyweight. In case of conflicting certificates, later in the blockchain wins. The fees for creating a heavyweight delegation certificate are the transaction fees for the contained transaction. A lightweight certificate is not published on the blockchain, but instead included in block headers to prove staking rights for the address that was elected slot leader. It also contains a "serial number" to break ties.

To set up a stake pool a registration certificate is created and embedded in a transaction that pays the pool registration fees to a special address. The certificate contains the staking key of the pool leader. People wishing to delegate to the pool must create (heavyweight) delegation certificates delegating their stake to that key. And using combinations of base and pointer addresses and "chains" of delegation certificates, a large number of scenarios can be covered, including: regular user wallets; offline user wallets with cold staking; wallets with enhanced privacy; staking pool wallets, and enterprise wallets for exchanges.

Transaction fees are an important part of Cardano's incentive scheme. When Ada is sent, a small fee is paid for the transition, to validate it. These fees help prevent Distributed Denial of Service (DDoS) attacks by imposing a financial barrier for any adversary intending to flood the network with spam transactions. The fees also provide funds for Cardano's incentives.

Incentives are distributed each epoch, the operation of Cardano's Ouroboros algorithm being divided into epochs that each last five days. Transaction fees are collected for the blocks created during each epoch, pooled along with Ada from monetary expansion, and the total is distributed to stakeholders, according to the stake they own.

For more details on incentives, transaction fees and staking, Lars' presentation is available in full: Incentives in Cardano.

Follow IOHK online for more details of progress on Cardano development, and watch out for a forthcoming video from the first Cardano developer meetup in London.

It's the end of April and it already feels like a long time since February, when we announced version 1.0 of Mantis, our Ethereum Classic client built in Scala. After the success of Mantis 1.0 some of the Grothendieck team got temporarily drafted onto other projects. That, coupled with the two-month full-time Haskell training course some of the team were on earlier this year, meant that Team Grothendieck has been short-handed recently. In fact, internally this release is sometimes called "The Konrad Release" as it was developer Konrad Staniec who kept the 1.1 candle burning and the performance pull requests (PRs) coming.

For review of the PRs we did of course leverage the expertise of the whole team, and special mention to Alan Verbner and Nico Taller for their efforts in review and testing of the performance improvements to the complex pruning functionality.

While I'm listing contributors, many thanks to Lukasz Gasior and Radek Tkaczyk for taking time to review PRs early on and especially to Carlos Montero and Jeremy Townsend, two new IOHK developers who jumped head first into the Mantis code just as the test cycle was starting and were invaluable in reviewing PRs and testing the JSON RPC API. Also the testing team's Alan McNicholas for giving the release candidate a whirl and finding an installer bug! That's quite a lot of shoulders to the wheel.

The objective of the 1.0 release was to create a working product, while the 1.1 release aimed to take the working code and find and remove the performance bottlenecks. The most painful bottleneck identified was in synchronizing the blockchain. This was complicated by the fact that tuning that performance depends on quite a few factors, the speed of the network, the type of hard disk on the machine and the number and type of peers at the time of synchronizing.

For example on MacOs with an SSD and 8Gb of RAM Konrad was consistently getting about 17 hours for a full synchronization, whereas on an "small" EC2 instance this could take over a week! One of the reasons for this is AWS t2.small instances can be "limited" or "unlimited" referring to their CPU credits per hour. Once the limit of CPU credits has been reached, the synchronization slows down considerably. Our developer Jeremy Townsend wrote this up and it turns out this can be improved by using a "compute optimised" EC2 instance because the software now spends most of its time actually verifying blocks of transactions and those crypto functions are compute expensive!

Apart from performance, the "difficulty bomb" ECIP 1041 has been disabled – just in time too as the block where this becomes important rolls around in early May.

There have been no changes to the wallet interface in this release. A couple of fairly minor changes were considered but the Daedalus team is flat out and while they are on the team’s backlog list they did not rise sufficiently in priority for inclusion in this release. The only real implication of that in this release is how the block download progress is reported. It was quite confusing for users to see a 0.0% progress bar for such a long time. The reason is the synchronization for ETC is different to the synchronization for ADA, in that ETC implements 'fast sync' and ADA does not.

Fast sync downloads the state trie and the blocks in the blockchain. Ada has no fast sync and downloads only the blocks. In 1.0 the state trie was downloaded before the blockchain and when the state trie was fully downloaded the blocks began to download. The progress bar is only aware of the blocks and so continued to show "0.0%" while the state trie was being downloaded. In 1.1 the situation is better but not perfect. In 1.1, as a result of performance testing and improvements the block downloading begins straight away and the state trie downloads towards the end of the synchronization. The user will see the progress bar update as expected, however towards the end of the synchronization the progress will appear to stall. This happens while the state trie downloads. While this is not perfect and needs to be fixed, on the plus side the whole process is faster and so the frustration should be less. Thank you in advance for your patience with this.

The next release will be Mantis 2.0, currently slated for the end of the year, around Q4. This will be a significant release with significant new functionality. The Project Manager for this release, Ravi Patel, and a full-strength team will be introducing this functionality as it is prioritized.

On a general note, I feel the progress in ETC is picking up pace. Observing the external ETC community it seems there has been a lot of good organisational work done and dedicated people involved. I'm more optimistic than ever about the future!

After returning from my yearly global sojourn, I wanted to update the Cardano community on the status of the project. Since the beginning of the year a lot has happened. Cardano continues to grow at a rapid pace and the project is evolving into a new stage. The Byron release back in September of 2017 was an experiment for IOHK. It's the first cryptocurrency we have launched as a company. It's the first time we've had to manage public release cycles, segregated stakeholders (the general public, exchanges, developers, etc). Furthermore, the Cardano project has half a dozen software companies collaborating on it, thus we have to invest a huge amount of time in coordinating, communication and timezone overheads.

Since the September release, we've learned a huge amount about all of these processes and also in dealing with the needs of our broader community. We certainly haven't achieved a Nirvana-like state of perfection, but processes have definitely improved.

I'd like to share some of these improvements as they are mostly hidden from the general public, yet have a huge impact on our ability to deliver a long-term roadmap. First, since September, IOHK has built a tremendous amount of project management capacity, led by Elieen Fitzgerald.

Under her department, Eileen has managed to capture business requirements, draft project charters, improve our resource allocation and budgeting processes, improve development estimates, get better weekly reporting and manage the inter-dependencies between projects. We have also had an increasingly easier time managing third-party relationships, like our partnership with Runtime Verification for the K framework, IELE, and smart contract research.

Some of the outputs of these processes are that we are moving to regular release cycles for Cardano, with the first cycle starting next week on Friday. Our hope is to cut a develop branch for release and then run the release through a rigorous QA cycle currently planned for one month. Over time, this cycle can be shortened through automation and parallel processes speeding up delivery. Updates will become more frequent, higher quality and encumber less user disruptions.

The goal of the project management department is to ensure when we give a date for delivering a feature, a release or a major update that the date and quality are delivered. This goal is one of the hardest to achieve for a software company and much more so given the nature of the software we build, but it's also incredibly important for those who rely upon us for their own commercial interests.

Over time our project management methodology will become increasingly public and eventually will be ported into a public GitHub repository. We'd like IOHK to follow a creative commons process that other software companies and projects in our space can benefit from, and add to, as they pursue their own projects. We'd like to explore lighter weight versions of the processes for DApp development so that our developer community can follow best practices.

Second, working with exchanges and others, such as Ledger, we've been systematically redesigning Cardano's architecture, APIs and other components to be more friendly for those who wish to use our software. For example, you can see our new APIs here.

Another output has been moving our development towards a specification-driven process. The first component of the Cardano Settlement Layer to be ported into this process is our wallet backend, with the following formal specification:

Figure 1: Cardano SL's Formal Wallet Specification

The goal is that each part of Cardano will be specified in a format similar to the one above. These specifications are implementation independent, will eventually be analyzed using formal methods and can be used as a basis for test suites and improvement proposals. 

We are aware that many want to build their own mobile clients or modified software. To this end, we've been exploring the best way of discussing a unified backend architecture. I would personally like to see dozens of wallets and great user experiences materialize for Cardano, but I'd also like to make sure that these experiences are useful, secure and easy to deploy.  

Over the coming months, large chunks of Cardano's code will be ported over to, or replaced with, these specification-driven designs. This likely won't be directly noticed by our users. Rather, users will experience indirect symptoms, for example things getting faster, like wallet recovery from seed, fewer issues connecting to the network, a smaller memory and disk footprint as well as other improvements.

As we now have the talent, processes and clear roadmap, Byron will continue to rapidly improve and become more feature-rich. The release we are cutting next week to QA will include paper wallets, much faster wallet restoration and numerous fixes. We expect it to clear QA in mid-May and for updates to be released to our users monthly thereafter. 

Third, the most anticipated upcoming release is Shelley. Shelley is a massive project with many workstreams and scientific dependencies. It also contains many social processes involving community coordination and management. Effectively, Shelley is about turning over the network fully to the users thereby decentralizing as much as possible. 

The work we have done with Byron has given us a great deal of knowledge operationally, about the best way of iterating towards Shelley; however, special care has to be placed on consensus. IOHK has developed a custom, proof of stake protocol called Ouroboros for Cardano. It has never been used in a cryptocurrency before and has a completely original design. 

Thus we have been extremely focused on a proper deployment of Ouroboros to the general public. Byron is running a version of Ouroboros with delegation locked to core nodes under the control of IOHK, the Cardano Foundation and Emurgo, and block rewards turned off, but when Shelley comes this cannot continue. Staking rights will be returned to Ada holders and delegation will be fully under their control. 

To be clear, Ouroboros isn't a forced, delegated, proof of stake protocol like EOS or Bitshares. It's a pure, proof of stake protocol where for epoch elections every active Ada account is factored in. Anyone who holds Ada in a normal address in the global UTXO has a probability of being elected as a slot leader regardless of the amount of Ada they hold.   

However, the reality is that most will not want or have the ability to host consensus nodes and consistently show up to fill the slots they have been elected to commit. Thus, we developed a delegation system and the concept of stake pools for those users. 

Briefly, anyone can run a stake pool. There isn't a minimum threshold of Ada or a special club. Rather, there will be a blockchain-based registration system and a special transaction type to register a stake pool on-chain. Registered pools will be listed in the delegation center of Daedalus and pulled directed from the Cardano blockchain thereby preventing censorship or bias. 

Over the last few months, we've had to invest a huge amount of careful design and security thought into the process of delegation. There are dozens of factors and scenarios to consider, from cold staking to automation of rewards. But we have converged on a reasonable design for the Shelley release, and a paper will be released soon on eprint.

The summary is that Ada holders can create a delegation certificate for the Ada they hold and register it on the Cardano blockchain. This process in effect separates stake rights from the spending keys for their Ada addresses. Thus the delegation certificates can live in Daedalus, but the spending keys could be kept offline on a paper wallet or ledger device for example. 

Delegation will be done through a special transaction and from a user experience viewpoint, via the delegation center in Daedalus. A user can find a stake pool they wish to delegate to, select it, and click a "delegate" button. It's just that simple. As we launch Shelley testnets, we'll experiment with different user experience flows, from length of delegation to partial delegation (splitting stake between pools).

Another advantage of this process is that unlike Bitcoin mining pools, as our protocol natively understands delegation, it can automatically pay rewards to those who delegated without having to trust the pool operator. At the end of each epoch, our goal is to close the reward pool through a special transaction, paying all those who delegated proportionally to their delegation amounts.

Some benchmarks and threshold will have to be conducted over the coming months to optimize for space and prevent penny-flooding attacks. We will also need to explore different user experiences including notifications and other user interface considerations. 

There are natural questions to ask. How will we ensure that when Shelley launches there will be enough stake pools to ensure a reasonable amount of decentralization? How will these pools establish their brand and reputation? We considered these concerns and decided to open enrollment for a collection of beta testing stake pool operators. 

The goal with this process is to identify a set of 50 to 100 independent entities that are geographically well distributed who would like to run a stake pool as a business. The process will progress as follows:

1. Collect as many applications as possible at https://staking.cardano.org/ until the end of April
2. Process and winnow applications until we have a good set of 50 to 100 candidates
3. Invite the candidates into the IOHK slack and begin discussions about hardware configurations, deployment strategy, docker images, etc
4. When the Shelley testnet is launched, invite the stake pools to register and work closely with them to beta test various scenarios and experiences 

These beta testers will not get a special advantage or consideration when Shelley launches. They are necessary to test Shelley's design and ensure our assumptions and choices are reasonable as well as improve deployment strategy and documentation. When Shelley launches, there will be a grace period where all those who desire to register a stake pool can do so and Ada holders will be free to choose to delegate to anyone they want. 

Once the grace period expires, auto-delegation will be turned off and rewards turned on: Cardano will be fully decentralized. 

In closing, Cardano is a huge project. There are so many brilliant minds, great engineers and parallel efforts that it's difficult to capture all of it in a single post, much less just convey our progress. What's amazing to me is that we have really great processes established and are daily moving forward (a fan made a great website showing our daily commits: https://cardanoupdates.com/). 

What's also amazing to me is how quickly our scientific research is moving from the lab to code. Ouroboros has gone through over a dozen revisions and now is converging to a state where we can bootstrap from the genesis block without a checkpoint (an industry first for proof of stake). Our sidechains research is state of the art and a paper is coming in May. 

We have also brought game theorists and programming language theory experts together. The output has been incredibly innovative with new accounting languages like Marlowe and an increasingly richer theory for incentives for stake pools, network maintenance and other topics requiring an honest majority for cryptocurrencies to run properly.

Figure 2a: The Marlowe Programming Language

I'm astounded how we are able to think in systems now and by the quality of the people on the Cardano project. It's taken years to build this team and go from dream to regular status reports. I look forward to achieving our milestones and seeing Cardano change the world. 

Artwork,

Mike Beeple