 Let me give you a little introduction about Alex. So I wanted to have, when I started IOHK, a testing framework for cryptocurrency development. So what does that mean? It means that I have a modular, concise library that people could use to build their own cryptocurrencies or model networks or test a new consensus algorithm. So I did what all people do in the cryptocurrency space. I started with Bitcoin Talk, and I float around and look at all the threads. And I found this one really interesting project called ScoreX. And the selling point was that it was written in Scala, and it was a fully functional cryptocurrency. It was only about 4,000 lines of code. Now, for comparison, Bitcoin has about 100,000 lines of code. And I said, well, that's really interesting. So I read the code. I looked at it, and I said, that's really smart. But what got me really excited about ScoreX is that there was another repo unrelated to it where Alex had written a cockproof for the FLPN possibility theorem. Now, I don't know about you guys, but not many people do that as like a hobby on their spare time. It wasn't for a graduate project or anything, it was just something he did. So I said, OK, he's really smart. He's really special. So we called him up, and we've been working with Alex and his team ever since. And he's going to show off some cool things about ScoreX, which is another open-source project. All right, Alex. One-one. OK. Hi, everyone. So my pleasure to be here, and even more pleasure to give a talk. And my talk is about ScoreX, the modular blockchain framework engine. And I'm Alexander Chippornoi. I am working on very interesting things in IHK research now. Previously, I used to be an NXT co-developer and also participated in some projects around Bitcoin. And let's start to talk about ScoreX, and the first part is what is ScoreX in general. So let's start with use case. My idea is it's easier to understand why do you need for a tool when you have use case in mind. And ScoreX is essentially a tool, as I've seen it. So consider you have some paper written, or maybe some paper read, and you want to go from paper to code. Well, for example, you want to implement new concerns protocol, like new proof of work protocol, or proof of stake, or whatever. And you want to see it in action after maybe some very simple simulation. So you want to plug it into some system, and to run a test bet on, say, tens or hundreds of machines, and to get metrics, and to see how's it working in a real life like environment. Well, another idea you can going to be implemented is, say, another transaction language. So you want to have the existing proof of stake protocol, say, bitcoins, and then you want to change on the transactional part of blockchain system. Okay, so for me, there was a practical need. And so I started ScoreX with some use case in mind, actually. The use case was to see some proof of stake protocols in action to get some metrics of existing proof of stake protocols, namely NXT and a few others. Another thing I used to be, well, there were two guys of us made permacoin implementation, the first one open sourced permacoin implementation, probably. And so, well, there was a need to have permacoin consensus protocol implemented, and then to plug it into some system, and to see how things are working in a real life like environment. So what's the problem? Well, now we have use case, consider it, and what's the problem with an implementation? So the problem is, if you are going to play around Bitcoin reference implementation, so that's more than 80K lines of C++ code only, and probably more than 200,000 lines of code at all in different languages, so that they have Python, testing scripts, and C++ core, maybe somewhat else. In the same way, EthereumJ is more than 55K lines of Java code. I think Go implementation probably is about the same order of complexity. NXT is more than 40K lines of Java code, and there is another very big problem. So actually, if you are going to look to a code base of working cryptocurrency, so it's usually very messy, because code base is also inherited many active acts from, well, actual cryptocurrency history. The simplest case when developers have a choice to whether make a hard fork or to have a more messy code because of handling each case, so they are always choosing the latter. And so with time, the code is going to be more and more messy, because developers cannot deny working system, they cannot deny production life, cryptocurrencies. So summarizing the problem that is hard to locate, hard to swap functionalities to deserve ones, and so it is hard to make experiments, it is hard to make prototypes, it is pretty hard in practice to go to fast prototyping. And so here scorex is coming, in general, the idea is to find fast way to inject desirable functionality. And that implicitly at least means the design is going to be modular. So you are going only to a part, only to a model you want to change or you want to replace. We also have already a family of frameworks. So the first one externalized framework is script, which contains scala implementations of some cryptography primitives, well, wrappers for some well-known primitives implemented by other guys. I'll give some details later. And also we have some testnet application running at the moment. There are just few nodes in the network and you can join and you can see some things in action. Also everything is open sourced immediately. There is no any bit of code in some closet repository. So you can see every commit and every commit in GitHub repo is what I have on my local machine. So everything is open. And also it has creative command zero license. So public domain license means you can do whatever you want with code base. There is no any restriction that that's the public domain. And it's maintained by IHK research. Well, it would be not fair to not to mention competitors. So I started in late 2014 and that was initially a weekend project. So I haven't thought it would become something bigger that time. And now I believe I was first with such an idea. Maybe. I hope so. And now there are some competitors. So the most interesting one is Intel's Sotus Lake. It's in GitHub. Also and the Intel corporation is describing it in the same way. So they are saying exactly the Intel Sotus Lake is a highly modular platform for building, deploying and running distributed ledgers. So the same idea. And a few more words about Intel's product before going into score details. So they have a modular design to basic kinds of models or consensus. They use term transaction family. There are some models implemented. Probably the most interesting one is proof of elapsed time. That's about leader election using trusted function to be run in trusted execution environment. Namely a cheap going with Intel SGX technology. They also have some S smart place implemented. And the language is Python. The license is Apache. Okay. So let's go back to score X and let me give some details on the score X. So the implementation language is Scala. Scala is functional language with strict static typing. And the Scala is targeted GVM platform, Java virtual machine. That means you can play with score X possibly with any GVM language. So Java, Closure, Scala, Kotlin, Groovy, Jython, which is Python for GVM. Or JRuby, which is Ruby for GVM. Or Fraggy, which is Haskell for GVM or whatever. And the development philosophy is around two points. So the first is to find a balance. So if we are going to implement some flexible design, well, it could be hard to understand if you are going to enter into it. On the other hand, simple code could be not flexible at all. So we need to find a balance and that's hard work. And we are doing everything possible to have somewhat good balance, to find proper notion of it. And another point is to give developer, which is going to implement prototype fast to give a maximum for free. And that's also a hard job. And let's take a look to design in general and let's think on how much it could be given out for free. So score X is about compact core, which is some functions you probably need in any blockchain system and also it is about some interfaces needed to be implemented. And core is intended to be always for free. Consensus model, it's doing exactly the job as you can imagine. So that's about to find a proper order of state updates of blocks. And you have to implement it if you're going to play with it or you can take ready if you're going to implement with other part of design. In the same way, transactional model is about transactional language and about notion of minimal state you need to hold in order to validate transactions. And in the same way, if you're going to play with it, you have to implement some interfaces or you can take ready if you are not going to play with it. So network protocols, P2P layer, that's partly for free, some basic things are for free, but you're also probably willing to extend network protocols and network layer is pluggable, so you just need to plug your own protocols in addition to these ones. The same for API. And having those parts implemented, you need to define application. Applications is just a wiring code for different models and application is really lean. I'll show you the example of complete application further. And well, wallets can fix there. Could be for free, but you can enhance them. Partly for free, let's assume that. So a model is part of an application which writes and reads certain parts of logs and also it's implemented some interface or some functions. We are going to take a closer look and before that, let me say about code quality. So we have as compact code as possible. Also hard task actually. And we are also having already pretty good test coverage, like 80% in combination with strict typing. That's pretty good. And we are also using continuous integration in order to avoid degradation to be apparent in repositories. So let's get started. We have some documentation. It's in the wiki of the repository in the GitHub. In order to install it on your machine, you need to have Java 8 SDK and for Scala, Scala build tool, SBT is recommended option. And we are going to implement on blockchain system. So here is the first example of dependencies we are going to input. So basics, scorex basics is about the core and scorex consensus is about two proof-of-stake consensus protocols to be set. So you need to set one of them in config, just one line of config. And scorex transaction is simplest transactions language. That's as simple as to transfer tokens from one public key to another. No inputs, no outputs. The simplest option. And in the same way, if you are going to use, for example, PIRMACO implementation instead of proof-of-stake, so you are changing the second line, so you are just importing another model. Then we are defining applications, so just some general settings and we are defining models. Simply. Then we are going to construct API. API is to be constructed from pieces in order to get UI for free. It will be shown later. That's it. And then we are also adding some network protocols. So here we are adding just protocol for exchanging unconfined transactions. You need to know transactional format. So it's not for free, so you need to implement that and just include it. And it will be wired automatically to other protocols. And that's all, yeah, that's the application. We can run and we are going to launch it. So we are just creating an instance and we are calling run method and now we have working full node. And we can communicate with full node already running with UI. Just go to browser and call port in settings settings. Default is 9085. And this UI is to be generated automatically. So you just need to wire paths in code and then you are getting this for free. So you can get new methods easily without thinking about design or whatever. In the same way you can add your settings here, default settings. So yeah, P2P port is 9084 and RPC port for UI is 9085. And in the same way we have implemented our testnet application called Lagonaki. It has permaco and implementation as consensus protocol and simplest transaction model. So exactly the tokens transfer from one public key to another. And you can launch it without installing anything but Docker. So just run Docker image. The image is on Docker Hub. You can run Debian package. You can install Debian package. Or you can go to run Lagonaki from sources by visiting another repository. And one enthusiast even has implemented block explorer for Lagonaki. So it's available at craptorivolution.me and that was made by enthusiast. So don't ask me about domain name. I don't have an idea. And here we see blocks, unconfined transaction pool and some general information. So yeah, and if you are going to run your own private network, so you have to set your own seats in config. So if you're going to change consensus protocol even, so just set it in Lagonaki.conf, just change the last line. So write instead of PIRMA, NXT or Quora. So there are three possible options. Okay, that's it. I'm not going to provide more details in order to be understandable in order to have compact presentation. And what's next? So current version is 127. We are going to another major release, 130. And that would be about flexible state model support. So now it's somewhat hard-coded to account-based. So we are going to implement very flexible solution to support both Bitcoin-like, so input outputs and Ethereum and NXT-like, so account-based models. Also, we are going to implement flexible signing schemes. For now, EDDSA 25519 is hard-coded in some places. And with 130 version to be implemented, we will implement another testnet called Tiergakia. We will have a new proof-of-work protocol, name it, roll chain, paper to be prepared around to be published. It will be Bitcoin-like transaction models, multiple inputs, multiple outputs, but more simplified language. So exactly about what was called generalized Schnur-proofs by Jan Kaminis yesterday. Well, and we also will have implemented improved difficulty adjustment and some more features interesting to play with, and white paper is to be published in coming weeks, I hope. And now about script. So script at the moment is implementation of encoding functions and also scalar wrappers for Java implementations of some hash functions including modern ones like Blake 2 or K-Chuck. And also it is about scalar wrapper 425519 signature scheme implementation from whisper system, which is being used in signal messenger on millions of Android devices around the globe. So we are not going to implement primitives by on. That's better to have. That's going to use well-known implementations. And we are going to add support for authenticated data structures. So local trees are already implemented, and now we are working on authenticated skip lists, and it will be in next major release. And it will be possible to change with just one line of code from in-memory persistence to disk persistence, and it will be well about efficient implementation also. So if you need for some persistent authenticated data structure on memory and efficient, so you can take a look to an upcoming release of script. And we are also willing to coordinate with enthusiasts around the globe, so let's have fun together. So we are willing to see contributions in the first place. If you are in code, you can write comments and send pull requests with just comments. If they are reasonable, they will be included. Then you can go to implement some to-dos. We have some of them in code. Just search for to-dos string. They are easy, so it's better to start with them. We also would be happy to see documentation in form of blog posts, articles, pages to be read, and send us. And bugs, always please report bugs found, and we would be happy to see bugs found. We will fix them as soon as possible. And you can also participate in bug fixing. That would be awesome. And if you want to implement somewhat more global, so you can, for example, use BitcoinJ classes in order to implement Bitcoin UDEX model and the Bitcoin scripts as Corex model. So wrapping BitcoinJ functionalities in some way. In the same way, it would be good to see Ethereum virtual machine implementation. Again, Ethereum J classes could be reused, I guess. And please reach us. So we have mail list, and we are reachable. We are GitHub, and you can write directly to us. So better write to me in the first place. I'm Corex director. You can write my email in our team directory. So that's basically all, dear audience. And I would be happy to hear your questions, feedback, proposals, and whatever you would like to say to me. Yeah, Thomas. Yeah, it's available. Oh, for testing, we are not using big files. And here is the problem, you know, when you are having a file like stated in paper, like 200 terabytes, you also need to build a miracle tree on top of that. And that's about a huge consumption of resources. So on paper, that looks promising, but if you are going to use really huge datasets, so we need also to handle many issues in terms of storage and computation. So for now, we are having a very compact dataset just in order to check something. Oh, sure, sure, sure. And by the way, we have no any responsibility for the code. So, yeah, don't use it in order to launch cryptocurrency or use it, but we have no any responsibility. And that's stated in the CC0 license. Yeah, that's not intended to launch production systems at all at the moment. Just proof of concepts, right? Yeah, Jan? So that sounds like something that really useful for universities to teach people about the protocols, right? Yeah, I hope so. Do we have any partnerships with universities yet with storage or work? So yeah, anyone is interested? You have one, right? Sorry? So if universities are interested in using storage... Well, we have some talks on that. So maybe wish you all about that as well, right? So maybe wish you all about that as well. Oh, yeah, yeah, yeah. And I would be happy, in fact, to help the academic community because, you know, I'm reading papers for breakfast and I'm thinking how to have the most flexible design possible to have every paper implementable on top of Scorax, actually. Well, sometimes that's not possible but in most cases I guess that's possible with minimal changes and maybe with no changes in the core at all. So that's all. All right, guys. Thank you so much for the breakout session. A couple more words about Scorax. We're accepting pull requests. It's an open-source framework. Anybody can use it. Anybody can contribute to it. We'll be hiring more developers over the summer to work on it full-time. We're also looking for interns and other people who may be interested on particular things. If you are an academic researcher, if you have an idea and you'd like to create a module or perhaps use this in your research, feel free. The license lets you do it. No charge, no royalties, no nothing. All I ask is you let us know so we actually can put you on the project page and get people interested in your particular project. The other thing is that we've tried to keep the code as concise as possible. Alex, how many lines of code are you up to for Scorax? You still here, Alex? Alex, run away. Oh, there he is. How many lines of code are we up to in the repo total? For Scorax. How many lines of code are we up to? So core now is about 3,700. It goes down. So it goes down. So initially that was monolithic system of 4,000 bytes of code and now core is more compact, but some more modules to implement it around that. Yeah, so Bitcoin has about 100,000 and so now we're down to four and one of the reasons why we wanted to keep it so concise is we thought if you were a professor and you wanted to teach a class, wink, wink, about cryptocurrencies, this would be a wonderful framework for you to use with your students because it's easy for them to actually go through the whole thing in a week or two weeks trying to understand the spaghetti code of ball that is of code that is Bitcoin core. All right, if there are no more questions, comments, concerns, issues yelling at us, thank you all for coming so much and it's been IOHK's absolute pleasure to be here and to present and also to sponsor this conference. We really love the opportunity and we're going to love to come back if we can. Thank you. Thank you.