 Hello, my name is George Agabov, I work at Cerocal, we are a partner at HKEY and we took significant part in development of Cardano-SL as cryptocurrency. Today I want to talk about several topics, about challenges that we encountered while developing Cardano-SL and a particular part of Cardano-SL which is called CUR. So as a first step I want to drive you through how models are structured in Cardano-SL in abstract and a little bit more detail. So for a start Cardano-SL is split to three significantly distinguished parts which are CORE, wallet and networking. So when development just started we did not have this distinguishing but then the code base grew and at some point we understood that communication and how nodes converse to one another, it's really like a separate functionality which is hard to write in the same place as you when you describe logical blockchain. So that's how networking part emerged and CORE which is logic uses networking. Also at later stage we started to develop not only the logic of cryptocurrency itself but also some interfaces which allow users to do some meaningful actions like sending transactions and so on and this is wallet and wallet uses CORE. So this is a basic distinction and I will talk mostly about these things. So if we talk about challenges they can be divided into several categories and first category I want to talk about is basically complexity and growth of code base. When we just started this project it contained less than 30 modules which already provided some functionality of blockchain. They were in implementation of Ouroboros with some additional possibilities for one to send transactions so on. It was fairly simple, mostly proof of concept implementation. But then as development went further for us to bring this to total working cryptocurrency we had to add a lot of functionalities to it like delegation, proper readiness generation which is called for historical reasons SSE. Update system was also another part and as you add all of these functionalities you start to realize that your code grows really really fast. So from 30 modules we quickly went to 100 and then we started to approach 100 and have and the problem was that you couldn't really reason well about it when it was just so many modules. So at that stage we approach number of refactorings, we split our code base to several packages and that's what you will see if you will visit our repository now. So I will just throw a number of examples. For example we have a package called core which is like a core of this cryptocurrency. It contains itself several definitions, some abstract definitions of blockchain, some very basic types like transaction and address, what is address, what is transaction and if you read it you will have already a quite good understanding of our architecture behind this cryptocurrency. Then we have for instance US module which is for update system and update system uses types and definitions from core but provides specific implementations, specific like refinements of these types which are suitable exactly for update system functionality. Also if we put, if we consider a block processing which is a very complex procedure because our structure is quite enhanced it's also not doable to have all these functionality written in just one package. So we put a lot of abstractions there, we have abstract definition for block processing but concrete implementation of block processing with regards to update system, these definitions also live in this package and this actually solves the problem of complexity growth of code base. And now if you, as I said, if you visit Cardano Solar Pository you will see number of modules and in readme for these modules you will see definition of what is that on that module did. So that was one challenge. Second challenge I want to talk about and perhaps the most significant one was a gap between research paper or boards and real life application which is cryptocurrency. So in research paper you consider very basic properties and you build consensus upon these properties but think the essence is that you don't define things to an extent that they are actually used in real life. For example transaction sending is really simplified in research paper and it's not even defined in the proper way but it's pointless to have cryptocurrency without transaction sending. So it's actually interesting how one would approach this. So initially we just sat on the table and had some discussions of what are validation rules of transactions. We developed a number of proof of concepts then we were working on some specifications and refined that implementation. Then when we encountered a problem of validating that what was developed at that time was proper we started to write tests and understood that our specifications were imprecise to many extents and that also contributed much to definitions. And actually it was a whole process, a whole framework of development that defines that way which is already partly described in other talk by Duncan. Second category of difficulties lean in the gap between research paper and real life application and this can be divided into two groups. First it's ambiguity of research paper which means that if we consider Ouroboros it doesn't define up to certain extents many things like transaction processing it just there just defined on the basic level because it's not considered by consensus actually. And second part of challenges is that we need to add some additional functionalities that are not even that consensus is not aware of. So let's first talk about ambiguity. I will just draw two examples of where ambiguity comes into place. First good example is stake and balance. Research paper doesn't have definition of stake in any ways different from balance. So if some user has some money on his account this is basically his stake. He's like a proportion of his stake relatively to whole stake of system. He reflects his right to participate in block creation and so on. But for several particular reasons you just can't have stake and balance defined as the same thing because if you consider what these two things actually are balance is values that you can transfer on the system which is like just money you pay to somebody and stake is right for participation. And if we consider concept of delegation it actually delegation is mechanism to transfer your stake without transferring balance. And when you come further on all of these definitions you understand that these two things are actually different. And furthermore if you consider how these things are actually implemented you will see that difference is even more deep. So how balance is defined? How we exchange balance? We define transaction which is number of inputs, number of outputs and you have transaction outputs of one transaction used into inputs of different transactions which are also defined this way. And transaction output is actually defined as pair of address and coin where address is identity of personal system and coin is amount of money you want to send to that person. And if we consider how address is defined it's like common notion in cryptocurrency space that you have it as hash of public key. And in the simplest definition you can use the very same public key for staking. So if you have identity with balance then you use the same identity for staking that that person holds that money, he has this address you from from ledger functionality you understand that that address is signed that amount of money. But there is quite a problem if you consider how you will create blocks then you will understand that you need to sign blocks with some key. And this key actually reflects your right for staking so it's key associated with stake. But if you sign a block with this key then you have to reveal this public key otherwise nobody will be able to validate this signature was done indeed by you. But and this brings you to a security concern that if your signature scheme is broken and you already revealed your public key then money on that were held on this address they're revealed. And like cryptocurrency typically approach this by not by not using address twice. So if you spend money from this address you spend all money from this address and you don't use this address and one more. But essence here is that if you have some money on such some account after you create block you still have this address in place and money are not spent. So there is this is a true security concern. For that reason we inevitably come into situations that we need to have two keys one is staking and one is balance key which are in some way coupled but they are two different keys and this is not in any way reflected in paper and it took some time to actually come up with understanding this these two are essentially different different things. So second example is transaction processing or as we often call it txp. So basic so this is question of how you validate the transaction that came to you is actually valid it's proper transaction and simple answer will be that you need to check signatures associated with transaction. So you validate that indeed person who sends that transaction was the owner of funds. Second you check that these funds were not spent before to avoid so-called double spending. And it's this these are concepts quite easy to understand but not that easy to implement because you have to be very careful about what you do. So just one example that we encountered over the course of development if you all all funds that are eligible to be spent are stored in so-called UTXO which is a set of yet unspent transaction outputs. And when you have transaction it spends it it it has number of transaction outputs from previous transactions which can be spent to like other transaction outputs sorry actually these are inputs. And what you have to do you have to check that each such transaction input it indeed exists in the current UTXO and if for concrete transaction you can do it in one shot you can just take each of these inputs and for input for input one check that it is in map for input two checks that it is in map it's quite easy process but if you don't actually modify map when you take all of these things you can at some point encounter that you can create a transactions with just the same input so one and two are the same thing and if you implement validation in wrong way it will be an easy way to hack into the system. And the only way to approach that thing is to write proper specification of what you that you don't only just check that this transaction output input was in UTXO and this also but you also check that when you when you check for the first transaction input second transaction input won't be the same record as the first and yeah and for those who are interested you can read a document which will probably be attached to this video we describe solar rules we have for transaction processing and you will see that it's actually like a large document and we believe that that document actually describes the flow that and it was reviewed for a number of times by different people to be sure that we check everything that we need to check so this was about ambiguity and now we talk about additional functionalities which is the second problem in area of gap between research paper and real life application and two examples here will be delegation and update system so delegation is it is finding in original or worse paper it's a very simple high delegation and descriptions there it doesn't provide you a good guidance on how to implement this and first question was should we have delegation and delegation certificates be posted to blockchain or should they be exchanged off-chain and if you go further to both of these concepts you will see that one is applicable for one use case other is applicable for other use case and you have to think actually what are the consequence of using one case other case for example so for delegation we have two types of delegation certificates lightweight and heavyweight delegation certificates and lightweight are these that are not shared on blockchain heavyweight are stored on blockchain and interesting and there are actually interesting properties behind both of them second is a little bit better in terms of privacy to some extent also in terms of blockchain usage and heavyweight is better in a sense that you can delegate more properly in terms of protocol itself in particular with regards to mpc which is a process for generating random number and we also had to go through process of understanding what is this what is this to write down both ideas to communicate to researchers that they agree that both that can be used that can be used also there was a lot of feedback coming through when and when you go through these definitions you actually start to refine what is your address because at some point you understand that address it's not just hash of public key but it also contains should contain some information about delegation so it's a long process and it was indeed a challenge and another example is update system and for and update system is not so it wasn't something that was in any way defined in paper we just were given a task that is this cryptocurrency cardinal it should support update system for users to be updated and there was actually like a broad question like but how update system for blockchain should be should look like and we came up with definitions what we call soft fork what we call head fork not that we came up but we looked at how it was defined for different cryptocurrencies we did a lot of work to understand how to avoid hard forks if you can do something with soft forks we put it as some more complexity but for the price of being allowed to do more in terms of soft forks and so on and it's also was the process that almost everything that we came up was immediately written down into some sort of specification but maybe not well refined just to share it with people and for people to ensure that we are doing not something stupid in the first place and so yeah okay so let's talk a few words about some other challenges except for this gap so another challenge that you that we started to encounter from the early days but more as we went further was performance when we developed first proof of concept we didn't put much effort to design networking so we implemented some basic solutions based on network sockets for nodes to be able to communicate one to other and the interesting outcome of that was that when we launched this proof concept implementation on a cluster of nodes it worked well for 10 nodes but for 30 it didn't work well at all and that was basically because networking wasn't well designed it was just some drafted implementation just to allow some communication and I think that was historical the first performance problems that we did see but as it went further there was a lot of a lot of details as it came into place for instance first implementation it was keeping all the blockchain in memory because it was fast to prototype this kind of thing but it was obvious that we couldn't leave a long time with it because blockchain will grow and in some year will have more than 500 megabyte for instance and it's not something that you can easily store in it's not efficient and there is no need to store all this stuff in memory so for that reason we moved to ROXDB database and have blockchain store on file system so that was also in in some way related to performance also when we've been developing such future-ish SHD wallets and actually it's another example when research paper zero gap between research paper as Ouroboros and implementation when we developed this thing initially specification told one thing then we launched it and we thought that it was very expensive in terms of commutation it's a bit more expensive than we expected so we need to refine the specification to put additional bits of information on blockchain but yeah so and it's all the way through and interesting that after we launched cryptocurrency we unsurprisingly saw quite new performance problems which weren't much before the launch an example is exchanges so we when we develop most of cryptocurrency we paid a lot of attention to core site which we described how full node will process things and put a little bit less attention to wallet site we just ensure that it will work for average user relatively fast and to some extent in proper way but when you when you start to launch the thing on exchanges you understand that it's completely different use case and it requires you to complete a different performance to put in place so it's all the way through and we are we are working out all these problems and we are we have now much better solutions and what are future challenges that we'll encounter now that we encounter now that and we will encounter rather soon so first we need to fix a lot of issues that came from users which is a consequence of launching cryptocurrency in real life so when we did some testing we had only like we could test it only to certain extent and now we've had so much feedback and as we process this feedback we hope Cardano cell will become much and much better after that we have to manage to roll out the civilization which will have very same concerns with refining specifications with performance it will also require developing number of additional functionalities and refine existing ones and as I also work on user features and like basically every every effort we take it's a challenge because it's it's always something new that's something that you didn't do before so we'll keep you updated thank you for listening this