Recap: Krakow Meetup (16.08.2018)

After the Warsaw meetup (which you can read about here), the Cardano Foundation team hopped on a train and headed south to Krakow. In Krakow, we organized a Cardano community meetup with help from a local community member, Maciej. We were thrilled with the beauty of the city and the great turnout with approximately 80 people in attendance.

The evening kicked off with an introduction from Jon and Tom from the Foundation. They talked about cryptocurrencies in general and the competitive advantages of the Cardano project. They also explained the three key partners who are involved: Cardano Foundation, IOHK and Emurgo and what their roles are respectively. For Cardano Foundation, our mission includes:

  • ensuring stakeholder accountability
  • shaping legislation and commercial standards
  • driving adoption and awareness of Cardano
  • growing the global Cardano community
  • facilitating partners

Lastly, Tom and Jon shared with the meetup attendees on how they can get involved. The best place for learning about Cardano would be the website: And for joining the community, we have our many channels:

Up next, we were excited to present our invited speaker, Duncan Coutts, Director of Engineering of Cardano at IOHK!

The first half of Duncan’s presentation included an explanation of why it is important to care about software quality and design and how this careful philosophy is applied to Cardano development. He also explains how it is important to incorporate many different areas of knowledge to create a great cryptocurrency. Duncan also shared a brief history of the project in terms of the development and exchanges supporting ADA.
To read details on the first part of Duncan’s presentation, click here.

In the second half of his presentation, Duncan delved deeper into how software is tested against the specification and gave details on a few of the Cardano workstreams.

Testing against Specifications

There are many testing techniques, but Duncan explained the approach chosen by IOHK for Cardano’s development and how it is extremely good for testing implementation against specifications. This approach produces great evidence for quality assurance. First, you start with the specifications from the paper. These have been written in such a way that can be easily constructed and turned into equivalent, computable Haskell code. This is the ‘executable specifications’. From here, you get an abstract function. This is where you get rid of details that don’t matter and focus on the things that do.

In the above image, the arrow symbolizes a change in the state of the wallet. The testing approach will compare values given by the abstract state and the real implementation, and you want to see whether the same number comes out. In large sequences of data (ie. blocks arriving, transactions coming in), there should be agreement at every state. If states are equivalent for all sequences of operations, then this is the evidence that the implementation matches the specification.

Duncan also adds here that there is a need to balance quality and time to delivery. There is a trade off of making things right but also with pushing out new features and updates. It is not possible to do a rewrite for everything, but in the case of the wallet, it was important.

What’s new in Cardano!

After explaining the testing methods, Duncan explained what’s coming for the project. Cardano is being developed to become a decentralized Proof-of-Stake protocol. Currently in its first release, it is federated, meaning it is being operated by 3 entities and is not fully decentralized. Decentralization in Cardano involves:

  • mechanisms to delegate stake to stake pools
  • incentives to operate stake pools
  • incentives to delegate to stake pools
  • and a robust worldwide P2P network

Delegation and Incentives

Ouroboros was always designed to be decentralized but to do it in practice, it has required new research and development. Hence, IOHK have published or are working on research papers on: delegation mechanisms, incentives design, and the engineering design for both. These areas of research have proven to be remarkably tricky as they require many design iterations (in particular incentives as there are many aspects to consider to ensure they come out correctly).

Delegation summary

In a Proof-of-Stake protocol, anyone who has coins, in other words has stake, has the right and obligation to take part in the protocol. Just as in Bitcoin, 51% of the users need to be honest. This means in PoS, 51% of the stakeholders must be honest and must take part in the protocol for the system to work. Duncan explains here that one of the difficulties in a simple PoS system is that you need everyone to be online all the time! That is why Ouroboros introduces a key feature of delegation that eliminates this need.

Through the mechanism of delegation, addresses are associated with stake keys registered on chain. These stake keys have an associated rewards account and these keys allow you to delegate your stake to stake pools. It is these stake pools that take part in the PoS protocol. Staking rewards are then paid out to rewards accounts:

  • these happen automatically at the end of each epoch
  • rewards are given to stake pool operators
  • as well as to stake pool members

It should be noted that “self-staking” is also possible. Self-staking would be done by making private stake pools.

There was a question from the crowd at this point asking whether it is possible for someone to not participate in the protocol AND not delegate their stake. Duncan responds that while this is possible in principle, it wouldn’t make much sense. When you don’t delegate your stake, you are missing out of staking rewards, which goes against your best interest. And beyond the financial loss, it also means that it reduces the amount of honest parties in the system. So it would be in your interest to either take part or to delegate.

Incentives summary

The whole idea of PoS to make it work practically, must be the ability to delegate to someone who is online and operating a server, and there have to be incentives to delegate. Otherwise, the system will fall apart as no one will be around to create blocks. You also need the right amount of stake pools. That’s where the incentives scheme comes into play. And a good incentives scheme requires careful design and analysis using game theory. Duncan laid out their design goals, which were to:

  • have people operate stake pools and do so correctly
  • have people delegate to stake pools
  • have a ’reasonable’ number of stake pools
  • prevent ‘centralization collapse’ where a few stake pools become dominant

It should be noted that for point 3, Duncan added that this ‘reasonable’ number of pools is still open for debate but that they are sure that it can’t be too few. For example, in Bitcoin, there are 5 major mining pools that control a vast amount of the hashing power of the system and many people argue that this is too centralized. For Cardano, they are currently looking at ‘100’ stake pools as a starting point. And the general idea is that in Cardano, there will be competition between stake pools to attract delegated stake. People who are delegating stake will also have the ability to change and move pools, which will be important to make sure pools don’t get too big.

Another question from the crowd is raised here on how Sybil attacks are prevented?

Duncan first explains what a Sybil attack is, which is when an adverse player subverts a peer-to-peer network by creating a large number of pseudonymous identities, using them to gain a disproportionately large influence. In the specific case of staking, the adversary would create multiple identities and create many different stake pools when in fact it is only one actor. To counteract this attack, there should be some sort of scarce resource that must be used up. Cardano has considered this problem by requiring stake pools to also use stake. When you register a stake pool, there is a slight difference in rewards that the pool gets depending on how much stake the stake pool owner contributes. Stake pools that have owners who pledge a large amount of their own stake can get better returns for them and their delegates. In a competitive environment, this will help attract delegated stake, compared to a stake pool where the owner does not delegate any of their stake. The system also restricts one from using the same stake towards creating multiple pools.

P2P Networks

Finally, Duncan presents on the last aspect of decentralization for Cardano which is a robust P2P network. Often, people think P2P networks are easy, but they are wrong. In the context of cryptocurrencies, there are many reasons why a robust P2P network is difficult. For example, home users are behind firewalls and that makes the internet not nearly as peer-to-peer. It disables someone from sending information to anyone else. As of now, there is little research on design proven to work and this area of computer science needs more research!

In cryptocurrency, there is also the added difficulty that everyone is anonymous on the network. Defending a network against attacks is easier on a permissioned system where you can rely on identity and pick out any bad actors. In this area, IOHK have used networking consultants, best available papers and academics in the area to help design a network that will be resistant to attack.

Scaling P2P networks can also limit performance. Duncan showed us an example using real world measurements, not simulations, for sending a 2MB block (current size of an average block) from London to various cities around the world using TCP/IP. As you can see from the image above, time to Paris is rather quick but when you look at other continent, it takes much longer. This is not a bandwidth constraint. Round trip times to Australia are not 5 seconds, but are actually a third of a second. This prolonged time is caused by the way TCP works and limitations of physics. At IOHK, they use these real-world measurements to calibrate their simulations. And these models also tell us that any blockchain system that works by sending blocks between peers, can only really get 1,000-10,000 nodes in a 10-second time slot. Therefore, be wary of claims of incredible system performance numbers.

Duncan’s presentation came to an end and the last hour of the meetup allowed community members to meet and get to know each other. Like Warsaw, we were happy with the turnout of attendees and excited to see the level of engagement. We hope to see this community grow and if you attended, please feel free to add any other comments below!

You can read about the Warsaw meetup and other bits of Duncan’s presentation here.

Watch the presentation and video recording of the Krakow meetup here:

You can also join the Cardano Meetup group in Poland and stay up to date on upcoming events here: