When I got off the plane at Bole airport in Addis Ababa on the evening of January 4, I did not know what to expect. It was my first time in Ethiopia, and all I knew was that my Canadian colleague Dr Polina Vinogradova, an IOHK formal methods expert, and I were supposed to teach a three-month-long Haskell course to a class of young Ethiopian and Ugandan women. When our students graduated three months later on March 22, it was the highlight of my professional life. Words fail to describe how very proud I am of these courageous young women who sacrificed so much to attend the class, who worked tirelessly and hard, eager to start tackling some of the most pressing problems their countries face.
I stand humbled, not only by their fierce intelligence and passion, but also by their gentleness and kindness.
The course had been organized by John O'Connor, IOHK's director of African operations, in co-operation with the Ethiopian Ministry of Innovation and Technology, and the Ugandan government. We had 22 students, 18 from Ethiopia and four from Uganda. All the attendees had studied an IT-related subject at university, some were just graduating, others had worked for several years in software development or lecturing at university.
Most of the Ethiopian students were from Addis Ababa, but some were from far away and had to leave their family and friends behind to attend the course. The four Ugandan students lived in a hostel, spending three months in a country strange and foreign to them, not speaking the language and unfamiliar with local customs.
Teaching students with such diverse backgrounds sounds challenging, but the fact that none of them had any experience with functional programming in general or Haskell in particular made it easier: knowing other programming languages does not really help much when learning Haskell, and can even be counterproductive.
Haskell is the most important programming language used by IOHK. It is a functional language, whereas most well-known languages are imperative and object-oriented. Haskell is high-level, mathematical, extremely flexible and expressive, not really mainstream; an ideal language for setting out our complicated protocols and cryptographic algorithms efficiently and in a provably correct way.
This is what one of our Ethiopian students, Bethelhem Teka, says about Haskell and the course:
Despite coding on imperative programming languages for more than six years, I was a stranger to the functional programming basis of Haskell. Initially it was exciting to internalize its promises of being functional, lazy, pure, no side-effects, and so on.
There are object-oriented concepts used in Haskell, but they are implemented differently, and it was weird to hear some facts like, no inheritance and no objects.
Obviously, there were many tough times on the course, especially when interpreting concepts into code. Being a crucial element of the language, understanding and implementing monad to achieve purity functionality was even harder.
There were many silly questions that came into my mind at different points, like wondering how Haskell kept its purity and avoided side-effects before discovery of monad, but these were soon answered by Lars or Polina or friends.
There are also other points that I need to take into my own assignments and dig further into for the future.
Finally, I feel lucky to have learnt the functional programming language paradigm as a whole and I find all its notions amazing and promising.
I cannot say that I have understood each and every concept covered in the course, but it has given me the confidence to start working on it and read more.
Circumstances were less than ideal, and we were facing problems all the time. The traffic was horrific and some of the students spent three hours every morning getting to class.
The internet was unreliable, and most of our students did not have access at home, which forced them to stay late after class to work on their assignments. Even in the classroom, we suffered many an internet failure and were forced to distribute material on USB sticks from laptop to laptop.
One evening, I got frantic messages on Telegram from those students who had stayed late to work on their assignments: they had been locked in! A security guard had decided it was time for his dinner, locked them in and left. It took some frantic phone calls, picking up a ministry employee with keys and driving to the building to free the students. They kept their good spirits, though!
Some of our students had problems with their laptops — insufficient memory, intolerably slow processors or faulty keyboards. After a slow and painful start, IOHK eventually provided better machines.
The Ugandan students neither liked the cool climate, nor were they happy with the unfamiliar Ethiopian food. Addis is 2,500m above sea level and the second-highest capital in the world, so the climate is cooler than one would expect from an African city. Polina and I felt so sorry for the four of them during the first weeks, they always looked so miserable!
Another problem, at least in the beginning, was the fact that the students were used to an education system where asking ‘stupid’ questions was frowned upon and where teachers were often unapproachable. It took patience and encouragement to convince the students to open up, to show them that it was okay to ask questions and to interrupt us when there was something they did not understand.
The students also seemed to be used to a style of teaching and learning that focuses on theory. In the beginning, they followed our lectures well enough, but did quite poorly when it came to practical exercises and to applying what they had learned to actual code.
Once we realized this, we provided more examples and exercises, and had them write code as often as possible. Repeat the Haskell workflow over and over again. Write some code. Compile. Fix errors. Test. Repeat.
It is a challenging course and goes far beyond a mere introduction into Haskell. Many advanced topics and concepts are covered, and a lot of material is squeezed in. This puts pressure on the students and requires them to work hard. But it is worth it! After completing the course, the students can be proud of a solid understanding of Haskell and are prepared to work on real problems.
For one project, the students had to implement a peer-to-peer protocol, and they were really excited to see how the abstract concepts they had learnt could be applied. In Bethelhem's words:
Working on assignments was the most favorite task among any of the activities in the course.
I was trying to understand and work on every question. Even though it was group work, each assignment had something to do with practical points and It gave me discomfort to miss one.
Therefore, if I didn’t code it, at least I discussed with the group to visualize it algorithmically. Working in a team was fun! It helped to know each other, and I do appreciate well organized and clean lecture slides. The screen recordings also helped a lot.
One novelty in this course was a two-week section about Plutus, taught by Professor Philip Wadler, one of the creators of Haskell. Plutus is the smart contract language developed by IOHK for use on the Cardano blockchain; it has been implemented in Haskell and is very similar to Haskell, so our students were in an ideal position to learn about it.
Another student, Bethel Tadesse, had suggestions for the course and the Plutus part:
About the course I really like it and it is very interesting and useful for me, also inspiring me to work more and more. It's really optimal that we can bring this relevant and efficient technology to our developing country Ethiopia and also Africa. I also proudly say that I am lucky to learn this, a life-changing and solution-making infrastructure.
It lets me see the brightest future. It is really helpful and well organized, except the time shortens and makes it stressful and more effort is needed from us. And in the smart contract session, honestly speaking, we take in only the basics not the details and in my conclusion we need a bit more clarification to work more on it further. And in the basics I found it really interesting and powerful in securing different areas which need to be handled by this technology.
As a suggestion, I want to say that it might be better with the smart contract session if we get more time to internalize and see it more in advance how it works with the powerful language Haskell than dealing with it apart from the Haskell.
After almost three months of hard work, many struggles, countless internet and power failures, after learning esoteric concepts like monads and equational reasoning and down-to-earth applications with web servers and databases, after disappointments about poor test results and elation about steady improvements and ‘aha!’ moments, after learning and studying and working and eating and having coffee together, after medical emergencies, family tragedies and sicknesses, after many little and larger triumphs, much laughter and much joy, after being scared of ghosts on rooftops in the night (no kidding...) and avoiding countless shoeshine boys, it finally culminated with a beautiful graduation ceremony at the Sapphire Hotel in Addis Ababa.
Watched by proud family and friends, diplomats and industry experts, and journalists and philanthropists, the students were awarded their certificates by Dr Getahun Mekuria Kuma, minister of innovation and technology, and Charles Hoskinson, chief executive and co-founder of IOHK.
Nobody was more proud, though, than me. The women were all wearing Ethiopian dresses, they were shining with excitement and joy; they looked so beautiful, I had to fight back the tears. According to my wife, ‘They had always been beautiful, but success made them gorgeous.’
Read Polina Vinogradova's blog - In at the deep end in Addis
Building on last week’s post by Professor Aggelos Kiayias, IOHK’s chief scientist, I want to use this post to discuss another choice we made when designing Cardano’s reward mechanism. The mechanism is designed to give an incentive to stakeholders to ‘do the right thing’ and participate in the protocol in a way that ensures its smooth, efficient and secure operation. As was explained last week, to ensure fairness and decentralization, the rewards mechanism follows three principles:
- Total rewards for a stake pool should be proportional to the size of the pool until the pool reaches saturation.
- Rewards inside a pool should be proportional to a pool member’s stake.
- Pool operators should get higher rewards for their efforts.
One necessary modification deals with pool performance. If a pool operator neglects his ‘duties’ and does not create the blocks he is supposed to create, the pool rewards will decrease accordingly.
Take the example of Alice and Bob who run pools of equal sizes. They are both elected as slot leaders with 100 slots each. Alice dutifully creates all 100 blocks in the 100 slots she leads, whereas Bob misses 20 slots and only creates 80 blocks. In this case, Alice’s pool will get full rewards, whereas Bob’s pool will get less. How much less exactly is controlled by a parameter.
In this post, I want to concentrate on another potential challenge to the Cardano principles and explain how we decided to overcome it. The challenge was mentioned at the end of last week’s post: How do we prevent one person from creating dozens or even hundreds of small pools?
Note that for very large stakeholders it is perfectly legitimate to split their stake into several pools to get a fair share of the rewards.
An example of a Sybil attack
Let’s assume that we are aiming for 100 pools and therefore cap rewards at 1%. Let us further assume that Alice holds a 3.6% stake. If Alice does not split her stake, she will only get 1% of total rewards. If, however, Alice splits her stake, putting 0.9% into four different pools, her reward from each pool will not be capped.
The challenge arises if a small but devious stakeholder is allowed to create a large number of pools (possibly under assumed identities). If he manages to attract people to these pools (for example by lying about his costs and promising high rewards to pool members), he might end up controlling a majority stake with very little personal stake in the system. How could this happen?
Let’s imagine that there are about 100 legitimate, honest pools. If we didn’t guard against it, a malicious player could relatively cheaply create 100, 200 or even 500 pools under false names and claim low operational costs and a low profit margin. Many honest stakeholders would then be tempted to stop delegating to one of the 100 honest pools and instead delegate their stake to one of themalicious pools, which might outnumber the honest pools. As a consequence, the operator of those malicious pools would be selected slot leader for a majority of blocks and so gain control over the blockchain, opening it up to all kinds of mischief and criminal activities, such as double-spending attacks! He would, of course, have to pay for the operation of hundreds of nodes, but that cost pales in comparison with the cost of acquiring a majority stake by buying the majority of all the Ada in existence, which would be in the range of hundreds of millions to billions of dollars.
This would be disastrous because the security of a proof-of-stake system like Cardano relies on the idea that people with a lot of influence over the system should hold a lot of stake and therefore have every reason to help the system run smoothly.
This type of attack, where the attacker assumes many identities, is called a Sybil attack, named after the 1973 novel Sybil by Flora Rheta Schreiber about a woman suffering from multiple personality disorder.
How can we prevent Sybil attacks?
One idea might be to make pool registration very expensive. But to prevent attacks, such fees would need to be extremely high and would prevent honest people from creating legitimate pools. Such a hurdle would be bad for decentralization; we want to encourage members of our community to start their own pools and not hinder their entry! There does have to be a modest fee for the simple reason that each registration certificate has to be stored on the blockchain and will consume resources, which have to be paid for.
Our game theoretical analysis led us to a different solution, one that won’t bar ‘small’ stakeholders from starting their own pools by burdening them with prohibitively high fees and a high financial risk.
When registering a pool, the pool operator can decide to ‘pledge’ some of his personal stake to the pool. Pledging more will slightly increase the potential rewards of his pool.
This means that pools whose operators have pledged a lot of stake will be a little bit more attractive. So, if an attacker wants to create dozens of pools, he will have to split his personal stake into many parts, making all of his many pools less attractive, thereby causing people to delegate to pools run by honest stakeholders instead.
In other words, an attacker who creates a large number of pools will have to spread himself too thinly. He can’t make all of his many pools attractive, because he has to split his stake into too many parts. Honest pool operators will bundle all their personal stake into their one pool, thus having a much better chance of attracting members.
The degree of influence a pool operator’s pledged stake has on pool rewards can be fine-tuned by a configurable parameter. Being a bunch of mathematicians with little imagination, we called this parameter ‘a0’. (A colleague suggested the Greek letter phi because it sounds like part of the nasty giant’s chant in Jack and the Beanstalk – ‘Fee-fo-fi-fum’ – and we’re trying to ward off harmful stake pool giants, but we’d be grateful to any member of the community who can come up with a good name!).
Setting a0 to zero would mean: ‘Pool rewards do not depend on the operator’s pledged stake.’ Picking a high value for a0 would result in a strong advantage for pool operators who pledge a lot of stake to their pools.
We have a classical trade-off here, between fairness and an even playing field on the one hand (a0 = 0) and security and Sybil-attack protection on the other hand (a0 is large).
To demonstrate the effect of a0, let’s look at the three graphs in Figure 1.
In the graphs, we are aiming for ten pools, so rewards will be capped at 10%. The size of the pool stake is plotted on the horizontal axis and the vertical axis shows pool rewards. Each graph depicts three hypothetical pools, where the operators have pledged 0%, 5% and 8% respectively to their pools (the pledged amount is called s in the graphs).
The first graph uses a0 = 0, so the pledged stake has no influence on pool rewards, and the three pools behave in the same way: rewards keep climbing as the pool size grows until they are capped when the pool controls 10% of the stake.
In the second graph, we see the effect of a0 = 0.1. The three pools are still similar, especially for small sizes, but they are capped at slightly different values. Pools with more pledged stake enjoy slightly higher rewards when they grow bigger.
Finally, the third graph shows the effect of a0 = 0.5. It is similar to the second graph, but the differences between the three pools are more pronounced. We still have to choose a “good” value for a0. This choice will depend on quantities such as expected operational pool costs, total rewards and – most importantly – the desired level of security.
We will want to keep a0 as small as possible, while still guaranteeing high levels of security against Sybil attacks.
In any case, it is important to keep in mind that the introduction of a0 does not prevent ‘small’ stakeholders from running successful pools because somebody with a great idea can always reach out to the community, convince others and invite them to work together and pool resources to pledge to the pool. In the end, running a solid, reliable pool and working closely with the community will be more important than just owning a lot of stake.
We have also started thinking about replacing the dependency of rewards on the pool leader’s stake with a reputation system. This would allow people with little stake to make their pools more attractive by running their pools reliably and efficiently over a long period of time. This won’t be implemented in the first iteration, but is on the table for future versions of Cardano.
You might also like to read the IOHK technical report ‘Design Specification for Delegation and Incentives in Cardano’ for a broader, more detailed description of the system.
On Monday, 5 November, IOHK will hold an AMA (Ask Me Anything) on staking in Cardano, where anyone will have the opportunity to put questions to the IOHK team. Details of the AMA will be announced soon.
Artwork, Mike Beeple
At IOHK, we are proud of our scientific approach and close collaboration with academia. We publish in peer reviewed scientific journals and present our results at acclaimed international conferences to ensure that our protocols and algorithms are built on rock-solid foundations. Our software must reflect this scientific excellence and quality, which means that we need a process to go from scientific results to actual code written in the Haskell programming language. We therefore decided to run internal training on “functional correctness”, so that the quality of our theoretical foundations can translate into equal quality for our code. We ran the first course over four days in Regensburg, Germany, two weeks ago. This training is aimed at everybody writing Haskell at IOHK, so we decided to run four sessions, roughly based on geography – there are IOHK engineers in 16 countries. We plan to do a second session in Regensburg in November and then two more early next year in the US. The lecturers were Andres Löh, co-founder of the Well-Typed consultancy, and John Hughes, the founder of QuviQ, who are both prominent in the Haskell world.
John is one of the creators of Haskell and the co-inventor of QuickCheck, the Haskell testing tool. Most mainstream software companies (if they do testing at all, which, sadly, is not always the case), use unit tests. For this, developers write down a number of tests by hand, cases that they deem typical or relevant or interesting, and then use a unit test framework to run the tests and report whether they yield the expected results. QuickCheck is different. Instead of specifying a handful of tests, developers using QuickCheck state the properties that their code should have. QuickCheck then generates many random test cases and checks the property for each of these. If QuickCheck finds that a property is violated, it first tries to simplify the test, then reports the simplest failing case back to the user.
As a simple example, let’s say you wrote a program to sort a list of names. Using unit tests, you would check the program against a few handcrafted examples of lists of names (something like "Tom", "Dick", "Harry" and "Dora", "Caesar", "Berta", "Anton" ). With QuickCheck, on the other hand, you would sit down and carefully think about properties your program should have In the example of sorting lists of names, what properties would you expect? Well, after running the program, you should get a list that is sorted alphabetically. Oh, and that list should contain all the names you entered. And yes, it should only contain those names you entered. You can write down these properties as Haskell programs, then hand them over to QuickCheck. The tool checks your properties against as many randomly generated lists of names as you wish (usually hundreds or thousands) and identifies any violations.
In practice, QuickCheck often manages to find problems that are overlooked by less rigorous methods, because their authors tend to overlook obscure cases and complicated scenarios. In our example, they may, for example, forget to test an empty list of names. Or there may be a bug in the program that only occurs for long lists of names, and their unit tests only check short lists. John had many ‘war stories’ of this happening in real life with real customers, where bugs were only revealed after a series of complex interleaved operations that no human unit test writer would have imagined.
Every Haskell developer has heard of QuickCheck and understands the basic ideas, but in complex real-world programs like Cardano, it is sometimes not so easy to use the tool properly. It was therefore great to have the intricacies and finer points explained by John himself, who has been using QuickCheck for 20 years and has worked with many industries, including web services (Riak, Dropbox and LevelDB), chat servers (Ejabberd), online purchasing (Dets), automotive (Autosar specification), and telecommunications (MediaProxy, Ericsson and Motorola). He helps find bugs and guarantee correctness every day. Given John’s experience, the training participants were able to spend about half of their time learning the finer points of QuickCheck from the master himself. It was tremendous fun enjoying John’s obvious enthusiasm for, and deep knowledge of, the subject. The rest of the session was dedicated to understanding the link between formal specifications, written in a mathematical style, and Haskell implementations.
At IOHK, we work very hard on writing correct code. For example, we specify program behavior and properties using rigorous mathematics. In the end, of course, we can’t deploy mathematics to a computer. Instead, our developers have to take the specification, translate the mathematics into Haskell and produce executable, efficient code. This process is easier for Haskell, because it is firmly rooted in mathematical principles, than for most languages, but it is still a conceptual leap. The specification talks about mathematical objects like sets and relations, which have to be translated into data types and functions as faithfully as possible. Nobody wins if your beautiful mathematics is ‘lost in translation’ and you end up with bug-ridden code. For example, when mathematicians talk about integers (..., −2, −1, 0, 1, 2,...) or real numbers (such as π, and √2), how do you express this in Haskell? There are data types like Int or Double that seem related, but they are not the same as the mathematical concepts they were inspired by. For example, a computer Int can overflow, and a Double can have rounding errors. It is important to understand such limitations when translating from mathematics to code. This is where the mathematician and renowned Haskell expert Andres Löh came in. He taught the participants how to read mathematical notation, how mathematical concepts relate to Haskell and how to translate from the one to the other.
For example, Andres presented the first pages of our formal blockchain specification and talked the participants through understanding and implementing this piece of mathematics as simple (and correct!) Haskell code, which led to interesting questions and lively discussions: How do you represent hashing and other cryptographic primitives? What level of detail do you need? Is it more important to stay as faithful to the mathematics as possible or to write efficient code? When should you sacrifice mathematical precision for simplicity?
In addition to their great lectures, John and Andres also provided challenging practical exercises, where participants could immediately apply their newly-gained knowledge about testing and specifications. Finally, there was plenty of opportunity for discussions, questions and socializing. Regensburg is a beautiful town, founded by the Romans two thousand years ago and a Unesco World Heritage Site. The city offered participants a perfect setting to relax after the training, continuing their discussions while exploring the medieval architecture or sitting down for some excellent Bavarian food and beer.
Artwork, Mike Beeple
The IOHK Haskell and Cryptocurrency course in Barbados brought together students and professionals who were interested in learning the Haskell programming language. The course ran for eight weeks at the University of West Indies. Barbados was the second time the programme was offered, after a successful inaugural course held in Athens last year. The goal of the course is to extend the computer science training of participants and introduce them to Haskell, an elegant functional programming language, in the context of the cryptocurrency industry. Haskell is the language used in the Cardano cryptocurrency, and it was chosen because of the security benefits it offers.
The course was designed and taught by Haskell and functional programming experts, including myself, and Dr. Andres Löh of Well Typed and Dr. Marcin Szamotulski, Haskell Developer at IOHK. Visiting lecturers included Prof. Philip Wadler, one of the creators of Haskell, and IOHK Area Leader in Programming Languages, and Cardano SL developer, Darryl McAdams. The instructors aimed to strike a balance between theory and practice, teaching the students both theoretical background of functional programming in Haskell in particular (Lambda Calculus, System F, Category Theory, etc), but also introducing them to popular libraries and important techniques for solving real-world problems (networking, parsing, resource handling, and more). At the end of each course, students are given the opportunity to apply for positions at IOHK and continue their professional career in Haskell.
Here are the stories of two students who attended the IOHK Haskell and Cryptocurrency course in Barbados:
Jordan Millar - Jordan is currently a chemist with an M.Sc. in organic chemistry from Oxford University.
Upon hearing that IOHK was offering a free Haskell and Cryptocurrency course in Barbados I decided it would be foolish to not enroll. The stars aligned for me as Barbados is a stone’s throw away from Trinidad and Tobago, my home, and I was acutely aware of IOHK’s approach to cryptocurrency.
My programming experience prior to this course was limited; I predominantly had written scripts in Python over the last two years. Only a few weeks prior to the course, I had become interested in Haskell through a functional programmer I happened to meet.
IOHK piqued my curiosity because at the time, they were the only company in the cryptocurrency space driven by research. This resonated with me as I had first-hand experience with research and development, albeit in a different field. I work in organic chemistry, and am currently working with a cleaning product manufacturer on their formulations. I appreciate the importance of developing a model, trying to break it yourself, and then having people smarter than you also trying to break it. In particular, if these networks are destined to hold hundreds of billions of dollars, you cannot afford to construct these networks in the ad hoc manner we have often seen before. With this in mind, I set off to Barbados to learn more about Haskell and IOHK’s methodology.
The course was a whirlwind tour of Haskell starting with data types all the way to type families and everything in between. We charged through a series of topics and on a weekly basis were given a problem sheet to complete. Dr. Lars Brünjes and Dr. Marcin Szamotulski were exceptional teachers. They delivered the content effectively and gave additional clarification when required.
The course was challenging, especially because I had missed the first week due to logistical issues. That being said, I came to find that Haskell is an elegant and concise programming language. IOHK flew Philip Wadler to Barbados to give a couple of lectures! What stood out to me the most was his demonstration of the Curry-Howard correspondence. It was fascinating to see the link between mathematical proofs and programs. IOHK’s Darryl McAdams also visited us in Barbados and took us through compilers in Haskell. The elegance of Haskell really shone here in my opinion as she effortlessly created a simply typed programming language during class.
It wasn’t all work and no play; IOHK sponsored many dinners and outings while we were in Barbados. This rounded off the course nicely as everybody had time to socialize outside of the classroom. To top it off, Charles Hoskinson took time out of his incredibly busy schedule to come and see us in Barbados. Having only seen Charles in YouTube videos, it was a privilege to hear him share his future plans and vision for IOHK in person. If you thought his conviction transmitted effectively through his interviews online, wait until you hear him in person.
All in all, it was a great experience. To anybody reading this, I highly recommend enrolling in this course if you get the chance to!
Rob Cohen - Rob divides his time between his information security consulting firm Callidus Security and serving in the cyber security field in the US military. He graduated from Columbia University in 2015 with a BA in Computer Science and Mathematics.
I was fortunate to be invited to attend IOHK's eight-week course, "Haskell and Cryptocurrency" in Barbados in early 2018. Prior to the course, my only experience with functional programming had been in a Compilers course I had taken in college and some toy projects I had built as experiments. As a result I knew this course would be challenging, and it turned out to be exactly the kind of deep-dive crash course on Haskell and functional programming that I was hoping for. This course was demanding, requiring dedication in the classroom and diligence in applying those concepts in our assigned homeworks and group projects.
The course covered a variety of topics, from the basics of IO and higher-order functions, to lambda calculus, optics, free monads, GADTS and Generic Programming concepts (and much more). Beyond the theory, what I found most rewarding in the course was working with my fellow classmates on our group projects. One project my team worked on involved building the early stages of a working Bitcoin client in Haskell! Working on larger-scale projects like that really helped Haskell come alive for me. Furthermore, guest lectures by Phil Wadler and Darryl McAdams from IOHK's Plutus team were pleasant surprises as well.
This course was not easy; there were times where I really felt my mettle was challenged. However, I stuck with it and pushed through. Now I not only have a deeper understanding and appreciation of the theoretical underpinnings of Haskell, but I came out as a developer with a stronger constitution as well. I am grateful to Lars and Marcin (the course instructor and teacher assistant) for all their hard work on the course. They put a tremendous amount of effort into the course materials and it showed. There were frequently times where their diagrams and explanations were better than Haskell's own official documentation!
The highlight of the course was the opportunity to work closely with such incredible developers from all around the world. My classmates hailed from Japan, Ireland, Argentina, Poland, Germany, Sweden, the USA, and the Caribbean. It was truly remarkable to have so many people from all over the world working together in one room trying to figure out how to learn Haskell. To my fellow classmates, I am deeply grateful for your support and camaraderie during the course. I salute you all for your dedication and hard work. I also look forward to our (spearfishing) reunion someday!
I can safely say that I've been bitten by the Haskell bug, and I look forward to being a member of the Haskell/functional programming community for years to come. I highly recommend this course to anyone who is interested in learning about Haskell and functional programming.
How Cardano's transaction fees work
The mathematician working on the protocol's incentives explains the research and IOHK's design
19 October 2017 Lars Brünjes 4 mins read
Why do we need transaction fees?
There are two main reasons why transaction fees are needed for a cryptocurrency like Cardano:
People who run full Cardano nodes spend time, money and effort to run the protocol, for which they should be compensated and rewarded. In contrast to Bitcoin, where new currency is created with each mined block, in Cardano, transaction fees are the only source of income for participants in the protocol.
The second reason for transaction fees is the prevention of DDoS (Distributed Denial of Service) attacks. In a DDoS attack, an attacker tries to flood the network with dummy transactions, and if he has to pay a sufficiently high fee for each of those dummy transactions, this form of attack will become prohibitively expensive for him.
How do transaction fees work?
Whenever somebody wants to transfer an amount of Ada, some minimal fees are computed for that transaction. In order for the transaction to be valid, these minimal fees have to be included (although the sender is free to pay higher fees if he so wishes). All transaction fees are collected in a virtual pool and then later distributed amongst participants in the Cardano protocol.
How are the minimal transaction fees calculated?
The minimal fees for a transaction are calculated according to the formula
a + b × size,
where 'a' and 'b' are constants and 'size' is the size of the transaction in Bytes. At the moment, the constants 'a' and 'b' have the values
a = 0.155381 ADA, b = 0.000043946 ADA/Byte.
This means that each transaction costs at least 0.155381 ADA, with an additional cost of 0.000043946 ADA per Byte of transaction size. For example, a transaction of size 200 Byte (a fairly typical size) costs
0.155381 ADA + 0.000043946 ADA/Byte × 200 Byte = 0.1641702 ADA.
Why did we pick this particular formula? The reason for having parameter 'a' is the prevention of DDoS attacks mentioned above: even a very small dummy transaction should cost enough to hurt an attacker who tries to generate many thousands of them. Parameter 'b' has been introduced to reflect actual costs: storing larger transactions needs more computer memory than storing smaller transactions, so larger transactions should be more expensive than smaller ones.
In order to arrive at the particular values for parameters 'a' and 'b', we had to answer questions like:
- How expensive is one byte of computer memory?
- How many transactions will there be on average per second?
- How large will a transaction be on average?
- How much does it cost to run a full node?
We had to estimate the answers to those questions, but now that Cardano is up and running, we will be able to gather statistics to find more accurate answers. This means that 'a' and 'b' will probably be adjusted in future to better reflect actual costs.
We even plan to eventually come up with a scheme that will adjust those constants dynamically in a market driven way, so that no human intervention will be needed to react to changes in traffic and operational costs. How to achieve this is one focus of our active research.
How are fees distributed?
All transaction fees of a given "epoch" are collected in a virtual pool, and the idea is to then redistribute the money from that pool amongst people who were elected "slot leaders" by the proof of stake algorithm during that epoch and who created blocks.
At this stage of Cardano, where all blocks are created by nodes operated by IOHK and our partners, fees are already collected (to prevent DDoS attacks), but they will not be distributed and instead will be burnt.
As soon as Cardano enters its next, fully decentralized stage, fees will be distributed as described above.
Coming up with a solid scheme for fee distribution is a challenging mathematical problem: How do we incentivize "good" behavior and promote efficiency while punishing "bad" behavior and attacks? How do we make sure that people who participate in the protocol receive their fair reward, while also ensuring that the best way to earn money with Cardano is to make the system as reliable and efficient as possible? The trick is to align incentives for node operators with the "common good", so that rewards are highest when the system is running at optimal performance.
These are questions studied by the mathematical discipline called Game Theory, and we are proud to have prominent game theorist and Gödel Award laureate Prof. Elias Koutsoupias of the University of Oxford working with us on finding solutions to this problem.
Director of Education