You. Hello everyone. I want to talk to you today about how to break into blockchain development using the Reach programming language, which leverages JavaScript as the primary way of programming and leverages an existing JavaScript ecosystem. Now this talk will primarily be about what the idea of blockchain is, what the idea of reach is, and not like a tutor tutorial about how to program it. If you want to see a tutorial, you should go to our website docs reach sh, which I'll talk about again at the end. Now, to start off, I want to explain a little bit about what blockchain is to help get some context for this. Now, I think that lots of people, when they think blockchain, they simply think that we must be talking about cryptocurrencies. Weve cryptocurrencies are. I think that some people, they have kind of a bad reputation where they seem to be some sort of crazy speculative scheme. Other times, if you think about cryptocurrency, people think about them as this grand philosophical experiment in defeating government power or something like that. And I think that there is a lot to say about cryptocurrencies and they're a very interesting and rich area. But I want to emphasize today that cryptocurrencies are not the only thing that blockchain is. And when I talk about breaking into blockchain development, I'm not really talking about cryptocurrencies. I'm talking about the technical tool of blockchain, which I think that we will see enter our technical lexicon in the same way that client server programming has or asynchronous programming, there's simply a new category of programming that is based on decentralized applications and blockchains. And that is what we're talking about today. Now, what exactly am I referring to? What is blockchain for as this core technology? Let's think about a traditional infrastructure weve. You're going to have a web application or you're going to have some sort of server application, and clients, whether on the web or on your smartphone or something like that, where you're going to have some way of paying for something. So normally the way that this works is that your client has a front end. That front end speaks to your back end server and your back end server will say, all right, it's now time to buy something. And it will tell a payment processor, this client has to pay me $10 and then the frontend will then communicate with the payment processor. For instance, maybe there will be like another window that will pop up. That will go to PayPal or to stripe or something like that. And then the payment processor and the front end will communicate together. The payment processor will say, all right, you got your $10, and then it will tell the back end that, here's the money, that the money came, and the payment processor will basically intermediate between the bank, the back end, and the front end. Now, that's sort of like a modern way that a payment processor works, but it is also possible CTO have a payment processor where the front end communicates to the back end. The frontend actually shares their payment information with the back end, and the back end communicates that entirely to the payment processor. So this would be an example of an application where your client directly tells your server what the credit card information is, and then the back end gives that to a payment processor. So, in both of these situations, in the version where the front end directly gives the credit card information to the back end, this clearly feels untrustworthy to some. Well, feels risky to some clients, because they don't want to share their credit card information with everyone. And that's why we've moved to the second kind of payment processing, where the front end directly communicates to the payment processor. However, the payment processor is still not the actual bank. The front end and the back end cannot communicate directly with the bank. And this is mainly for technical reasons that they just don't speak the right. They don't use the same tools. There's not, like, a unified way. CTO, if my bank is Wells Fargo and your bank is chase or something like that, then there's not, like, one way to communicate with them. And that's basically the service that the payment processors are providing. But these payment processors, in providing this service of intermediating, it allows them to impose constraints on front ends and back ends. So, for instance, it allows them to charge fees. And those fees, they're providing a valuable service. I'm not saying that the fees are, like, inherently immoral or something like that. Built the fees, make it so that the payment processing is more expensive than it intrinsically has to be. Similarly, the payment processor is in a position of trust. So imagine if a back end says, I need to be paid $10, and the payment processor actually tells the front end that you need to pay me $15. And then what it does is it pockets that $5. Now, a payment processor that did this would be probably quickly found out, but it does have the power. CTO do this, and there's no way to enforce, as part of your system that a payment processor doesn't do that. So this scenario right here describes how payments typically work right now on the web. And what blockchain allows to happen is to remove the payment processor and CTO have the front end and back end directly communicate with, quote, the bank. Now there's another thing that blockchain allow you to do, which is to have trustless databases. So here's another scenario. A front end communicates with a back end that manages a database. This infrastructure obviously describes thousands and thousands of applications. And a key thing about this setup is that the front end does not directly communicate with the database because it doesn't directly communicate with the database. This provides the feature of the database being able to obey certain invariants, have certain performance characteristics and so on. So there's desirable reasons to do this, but the downside of this is that because the back end completely intermediates access to the database, the back end can control the database in a way that the front end may not like. So as an example, a social networking site does not provide you access to your social networking data like your photos and whatnot. It holds those for you. And so it can, for example, censor them, it can sell them to somebody else. It can change them behind your back without you knowing. It can sort of rewrite the past. So because the back end is the only one that has access to the database, it is in a position of trust. Now, this database, you can kind of think of this as being an example of the quote ledger that the bank is managing. The bank. What it does is it manages a database that says, jay has a certain amount of money, Chris had a certain amount of money, Sarah has a certain amount of money. And that is just a particular kind of database. And anytime that a database is centralized, that means that the central holder of the database has control over the data and can change it. And that means that if you use this database, you have to trust that the provider will not modify it in a way that you don't like. Blockchain is inherently a technology to create a situation like the following, where clients and quote servers are peers inside of a network where they communicate with each other and they communicate with a decentralized ledger. This decentralized ledger is just a database that stores information. And the database that stores your account balances is just a particular kind of database. And there is really interesting cryptography and technical techniques for how these databases and ledgers are managed. And if you're really curious about this, I encourage you to go learn about that. But as a blockchain programmer, you don't actually need to know the details of this, just like you can use an SQL database without knowing exactly how query optimization works. Maybe you know that query optimization exists, but you don't need to know exactly what the details are. And the same is true for blockchain programming. Now the reason that cryptocurrencies come in is because blockchain was originally discovered CTO manage a ledger of balances. And so that's why that was just kind of the first database. But blockchain programs have evolved to support arbitrary databases. Secondly, when you use blockchain as a payments platform, then you're paying in whatever the tokens are of that particular blockchain. And so that of course will enter into your calculus when you're designing your program. So for example, it's very obvious to sell books for us dollars. But if you want to sell books, for example Algorand tokens or Cardano tokens or Solana tokens, then just sort of your business becomes operationally more complicated because you have to make sure that you're not losing money in the conversions. But of course the trade off for this is that you get this trustless payments platform. My personal opinion is that the complex of managing the payments angle is unproven and risky because of the volatility of cryptocurrencies. But the trustless database, that technology is ready to be used right now for all sorts of interesting applications. All right, so this is what I mean by blockchain. This is the space that we're talking about. And what I want to do for the rest of the talk is tell you about what it's like to program on blockchain today and what are some of its difficulties and how we at reach have designed a programming language and platform that makes programming in this world easier. Now the first issue about blockchain programming is that it is extremely low level programming. Now what do I mean by low level programming? Kind of intuitively, I think that weve familiar with the idea that you have programming languages that are like JavaScript, that are very high level. Maybe we could even imagine that there's even a higher level than JavaScript. So for instance, if you're going to have SQL, an SQL program is at an even higher level of programming than JavaScript. And then you've got JavaScript, and then you have programming languages like C and C Plus plus, and then you have underlying machine languages like assembly. So there's this hierarchy of programming languages where we kind of intuitively understand that as you get closer to the hardware, it becomes more complicated. CTO write the programs because there are more details that you need to manage yourself. And ultimately, when you get down to the actual hardware, meaning like the circuits and whatnot, it's almost like the skills of programming don't even really apply in the same way, because you're not really designing a program, you're designing a circuit. Now, of course, if you understand circuits very deeply, you might be able to think about them as a special kind of program, but it's a very different kind of program. Now, the thing is that right now, the sort of the standard way of developing blockchain programs is very low level. And that's because the main thing that you need to think about when you write a blockchain program is you're designing a state machine. Now, I think that many of us are familiar with the concept of a state machine because we use them when we're designing reactive components and whatnot. But the basic idea of a state machine is that you have a particular set of finite states that describe what is relevant about a program, what is relevant about some data, and then you have edges or transitions that correspond to what actions users can take. And if a user takes a certain action, then you manipulate the state in one way. And when you program blockchain programs, typically what you need to do is you need CTo either explicitly or implicitly design this state machine where all the arrows that are the transition arrows basically become functions on what is called your smart contract. And because these functions are spread out across your entire program, they have to be programmed in a very particular way. They have to start off by double breaking to make sure that they are called. While the program is in the correct state, then they need to take the external actions that correspond to whatever this arrow does. Then they need to update the state. And because of the way that most programming languages for blockchain work, this state machine is entirely implicit, but you have to manually program all of the arrows. And so it's a very complicated style of programming. One of the most popular languages for blockchain programming right now is called solidity. I want to show you a little snippet of solidity code. So this right here is a little snippet of solidity code. It's a c like languages. And when I say c like language, I mean syntactically, it looks very similar. CTO C. And it's kind of a class oriented language where the state of your program is implicit in the instant variables of your objects, which are called contracts. And one of the things that you do, if you look here on this middle line where it says require, one of the things that you're constantly doing is each function in your contract corresponds to one of those transition functions. And the main thing that you do is you put at the start of a program, a start of a function, a whole bunch of checks to make sure that you're in the appropriate state. And then once you're in that appropriate state, you then make the modifications, and then you emit events so that others can tell that an event actually happened. Now, this program is a very, very small program to just give you kind of a sense about what the shape of a solidity program is. And programming in solidity feels like programming in a c lines low level programming language. And I say low level programming language because there are lots of low level details that you must think about all of the time when you're programming in solidity. For example, when you program in solidity, you have to make sure that you never use more than 16 local variables, because otherwise you will overflow the stack. So that's the sort of concern that normally you only think about when you're programming an assembly. But something like that is relevant to solidity. Now, this program that I have up here, we don't need to belabor the details, but this is a complete program that does something useful, but it's not really representative of the kinds of programs that people write. In contrast, you may have heard of the program Uniswap. Uniswap is one of the most popular programs right now on the Ethereum network. And here's a snippet of a single one of its functions. So this is a very large program that there's a lot going on here. And of course, I don't expect you CTO, be able to understand or follow this, but this is actually a copy from the real source code. I haven't really modified it anyway, I think I deleted three new lines in it. But even from this, I hope that you can get a sense that some complicated things are going on in this program. We have to be very particular about checking our state. The very first things that happen up here in the beginning of the program where it says require, require, this is us checking the state. And even though this program does fit on one screen, one of the things that you'll notice is that there's this little comment about halfway through that says scope for token zero and one avoid stack two deep errors. So that means that even in this small program, the issue about running out of stack space is relevant for the programmer of this function. So when I say that as a solid programmer, you need to pay attention to low level details, I hope that it's clear that I'm not being too flippant about this, and that normal programs that you find in the wild actually deal with these issues. And so what this means is that as a blockchain developer with traditional tools, you need to have a lot of expertise in this low level machinery. Now what's worse, in my opinion, is that CTO design this program, you really do need to have that state machine model in your brain built. The state machine is not actually in your program anywhere, because your program is simply the arrow, the transition arrows. It's not the state machine itself. Now I want to show you a little sample of reach code. This right here is a complete reach program that when you compile it corresponds to roughly, I don't know, one or 200 lines of solidity code. Now of course you don't know what this program means. I haven't explained it, and it's a very different program. But one of the key ideas inside of Reach is that when you write a reach program a you're programming in JavaScript. It's sort of like you're programming in JavaScript with kind of like a weird library. And in this library you take the perspective of a detached observer who is observing other entities participating in a communication, in a decentralized computation, where you say, oh, well, at this part of the program, Alice does these things, and at this part of the program over here, Bob does these things, and Alice is going to share this information and Bob is going to receive that. Rarely everyone is going to receive it, and then Bob is going CTO do this thing. And so when you write a reach program, it's almost like you're writing the Javascript of a play. You have this detached perspective where you say these people do these things, and you never explicitly have to manage or think about the state machine because the state machine is derived automatically from the interactions that are actually possible in your script. So by kind of an analogy, if you were to look at the rules of a board game, then the rules of the board game will say something like, oh, well, the white player does this, the black player does that, then the red player does these things, and here are the options that they can do, and it says what is possible. But if you were to take that rulebook and then try to make a concrete program that enforces those rules, it would be a major endeavor, which is why there's not sort of routinely digital versions of all board games. Essentially what reach is is it allows you to do that conversion process automatically, and that's what it does for you as part of its compiler. So it makes it so that you can ignore all of those low level details about how to set up your state machine, about how to verify that you're in the right state, how to set up the transition functions, how to worry about what the stap depth is. It does all of those things for you. But this is just talking about the level of abstraction that reach provides. Blockchain programmers are not only programming at a very low level, they're also programming something that is very, very complicated. In particular, they're using some of the most complicated things in programming. So what I mean by that is that there's a complex tool, which is a low level programming language like assembly or c or solidity, and then there is a complex domain. So as an example, if you're programming a picture breaking site, then this is a relatively simple domain. But if you're programming a picture editing suite, then this is a very complicated woman because you have to deal with all sorts of complicated ideas like, I don't know, gaussian blurs and retouching and contrast. So you have to learn about all sorts of intricate algorithms that correspond CTO, the domain that you're working in. And traditionally, blockchain programs are also using a complex domain. They integrate things like cryptography, where it's very common for blockchain programmers to have to have an intuitive grasp about things like private keys and signatures and producing hash functions. And that's because the low level languages that are typically associated with blockchain don't support the creation of a wide variety of libraries that deal with these things because they're basically focused on just like a different level of the problem. And so one of the things that we try to do in reach is we try to make it so that all of the key ideas in cryptography that are relevant to blockchain programming are described based on their features, not on their implementation. Let me just give you a tiny example of this. Something that shows up a lot in blockchain programming is that two people would like to share something simultaneously. Well, sharing something simultaneously is not possible on an actual network because one person is going to do something first. And if I want to share something, if we want to share something at the same time, then I could just wait for you to share it, read what you do, and then have my action be based on what you did. So the problem of simultaneity is a problem with computer networks. Well, cryptography has a solution for this, which is that we can break a simultaneous sharing into three steps. I share something secretly, you share something publicly, and then I reveal what I secretly decided earlier, since I have to share what I did first, secretly. That means that what I do cannot be based on what you did, since you have to share it before I do something, before I make it public. That means what you do can't be based on what I did. Therefore, we had CTO have made the decision simultaneously, even though we do not actually share it simultaneously. So this is called the cryptographic commitment pattern, and there's all sorts of interesting ideas about how to realize this on particular crypto networks. But in the reach programming language we simply have the make commitment and check commitment as concepts in the language. Another example of something that is complicated about cryptography is that complicated about blockchain programming is that to do blockchain programming you essentially have to be writing a concurrent program, a program that has to deal with the asynchronous sending and receiving of messages by many different parties, managing them as they code and go. And this is of course one of the most notoriously difficult things to program about. And I think of that actually, as you and I, as JavaScript programmers, we're some of the people who are most expert at this because we've been able to build promise libraries and many different concurrency primitives inside of our Javascript programs to deal with concurrency. And one of the things that reach does is it basically takes the Javascript model of concurrency and applies it to blockchain and covers over and abstracts all of the low level complexities that blockchain imposes with regards to concurrency. And a big part of that is that script participant based way of designing your program. So by saying that the way that my program works is that Alice does this, then Bob does this, and then we enter a phase where red and green can take turns doing something, or maybe they can do things simultaneously, and then when they're done it goes back and Alice does this other thing. And so by describing who can do what when and then deriving what the concurrent rules are for the programmer, we can greatly simplify their programming task. So these are two ways in which Reach provides these features, and the main tool that we use in reach to provide this is a compilation technique that's called Endpoint projection. Endpoint projection is a tool that I developed during my phd that's based on program slicing, where you take that JavaScript based program that has many perspectives simultaneously. And we split the program apart into a component for each actor. So as a simple example, imagine that you have a client server program where the client says a and then the server says b, and then the client says c. Well, you know that from this description, when the client says a, the server must expect to receive a, and if the server says b, then that means that the client must expect to receive b. So from a description that is detached, you can derive the component for each one of the participants where the actor who instigates something had sort of the active role and everyone else has a passive role. And we can generalize this idea to an arbitrary number of participants and an arbitrary number of actions, provided we have a way of defining what it means to be the, quote active person and the passive person. And so our compiler is based on this idea. All right, let's move on and talk about something else that's complex about blockchain programming, and that's that blockchain programming is inherently dangerous. Now when I say dangerous, I don't mean that it's like sharp and pointy and you're going to poke yourself. I mean that because a blockchain program is automatically providing access to something that is traditionally protected behind the scenes of a centralized server, for example, it's automatically providing access to a bank, bank funds, or it's automatically providing access to a database. That means that your blockchain program, if there is an error, you have now exposed the entire database to control by arbitrary people on the outside world. So imagine how bad an idea it would be if you and I could just log in to the redis database or to the DynamoDB database that manages Amazon. This would be a terrible idea because we could break things. So when you program on blockchain, you are basically doing that. But what the blockchain provides is not only does it provide access to the database in the ledger, but it provides access in a way that is constrained. So what I mean by that is that you can say that the only way that you're allowed to modify this database is if, for example, you only increment numbers. And so there's this field somewhere and anyone can change it, but they can only make it bigger. That would be an example of a really simple constraint that can be imposed on a blockchain program. But figuring out if you made the right constraints is very difficult. And you may have heard of a wide variety of attacks and losses that have code about because blockchain programs fail to do this correctly. So one category of those are losses of access, CTO funds. So because a blockchain program manages access to funds and a database, if the program enters a state where it will refuse to accept further messages, then that means all of the funds are completely inaccessible forever. Another thing that can happen is that there can just be an actual hack and loss where when you expected to only give away your money to Jay, but you accidentally made it. So you give away your money to Jay and Chris. And so that would be an example of a hack. The using is that blockchain programs, by their nature, are what's called immutable. You launch the program, and then you can't really update it because the program's source code and its compiled representation is like part of its identity. So what this means is that the risk of writing the wrong program is higher because you can't update the program later. Now, the way that people do this in practice is they use a tool that's called formal verification or verification. So, verification is a very straightforward idea because you're already doing it. When you write a program, you check to make sure that it works. There's a variety of ways that you can check to make sure your program works. You can write tests, you can write unit tests, you can write end to end tests. You can build experimental use cases that are like end CTO, end integration tests, or something like that. The problem with testing is that testing is, by definition, finite. So you either have written 100 tests or 1000 or 10,000, but your program will be used in more situations than you could possibly test finitely. It is possible to do what's called property based testing, where, rather than writing a single test, you write a program that generates tests, but you can only run that program for a certain finite amount of time. So you only tested it for ten minutes, or you tested it for three days or something like that. But your program will actually be used in an infinite number of situations. The way that we typically do things in blockchain programming is by taking your program and turning it into a mathematical formula. And if that mathematical formula obeys some properties, then your program does or doesn't have an error. So maybe you have heard of gaussian elimination if you took, like, a linear algebra course when you were in college. But gaussian elimination is a really classic way of solving linear equations. So a linear equation would be something like x plus y is greater than ten, and three x plus three y is equal to, I don't know, 66 or something like that. I don't know if that's actually possible to solve. And then you can take this set of equations and solve it. Well, what formal verification basically does is it takes your program, turns it into a system of equations, and then tries to prove a property about those equations. One of the things that we do in reach is we make it so that your program is automatically turned into the system of equations. And we automatically prove that it does not have the hacking properties and the loss and the loss properties that we can guarantee that when your program runs, it will always obey certain basic properties that all blockchain programs should have. And we give a mechanism for you to add those to your program, add new unique ones to your program. So you can essentially write your program as if you were doing testing, as if you were doing property testing, and as if you were just including assertions in your code. But those assertions will not be complex into runtime checks. They will be compiled into compile time checks that will always be checked, or else your program will fail to compile. Now, Reach is providing this because it has that high weve way of programming. If you didn't have that high level way of programming and you just had the raw low level program, then you would actually need to create more artifacts. You would also need to create a state machine diagram. You would also need to create some sort of way of saying what paths through the state machine are valid. And then you would be proving properties relative to that state machine and relative to those properties. And so what this means is that doing verification is harder when you use one of the low level tools. And it's an optional step that you might not choose to do. And it's an optional step that you may not have the expertise to do. And so what this ultimately amounts to is that doing blockchain programming directly today without a high level language like reach, is very expensive. It's expensive because you need to have technical skills and expertise in using a low level program, programming in a complex domain, and being an expert in, say, formal verification. But what reach does is it removes all of these limitations. It makes it so that you can program at a high level of programming. You can program in a simplified woman, where we've produced abstractions that make sense for the domain, and you can program with a safety net that's guaranteeing that you're not making any mistakes. Another thing that happens with blockchain development that I feel that I need to talk about. It's not really a technical issue, but it is a relevant issue. And that is that blockchains tend to be very quote, tribal. Now what do I mean by that? Well, because each blockchain has its own cryptocurrency, there are basically people that have really bought into a particular cryptocurrency. So imagine that you have invested your life savings in JCoin and your friend invested their life savings in Chris Coin. Then regardless of whether or not JCoin or Chris Coin is actually better, or the J network, or the Chris network, or the know blockchain, you've already committed your assets to it. And so this means that you are going to support that chain hell or high water, and you're going to argue that all chains are terrible, all other chains are terrible, any limitations of the J chain are not so bad, and so on. And this is something that in fact actually happens right now with blockchain programming. And what's worse is that because each blockchain tends to have its own tools and low level languages. Earlier I mentioned solidity, and I'm not trying to pick on solidity. Solidity is just representative as the most popular way of doing blockchain programming right now. But there are a wide variety of other languages as well, and each one of them is basically tied to particular networks. And all of them are kind of, they're all cut from a very similar cloth, they're all low level, they all have, there's pros and cons to all of them. But those pros and cons are very hard to communicate about and collaborate on. Because the blockchain development community is not unified on the idea of blockchain. They tend to be focused on a particular network and a particular can in part because people's life savings are tied up in that particular cryptocurrency. One of the things that we try to do in reach is that when you program a reach program, you can actually compile to almost any back end blockchain platform. And so that allows people that are otherwise antagonistic to one another to collaborate, making reach programs and helping one another learn reach and learn blockchain ideas because they can communicate at this higher level of abstraction. And then of course when they go to deploy, they can deploy to whatever their favorite chain is. And so this is something that I think is a novel benefit to using a high level language like Reach, that we can eliminate some of that tribalism in the community. Now, in summary, I want to give you five take home points about Reach. When you program in Reach, you're programming in JavaScript syntax with something that is almost identical to JavaScript semantics. So if you are here at 42 as a JavaScript programmer, you basically already know Reach. The main thing that you need to learn is this high level semantics of orchestrating a decentralized computation. And that high level semantics is very similar to how you might currently think about doing client server programming. But rather than thinking about client server programming, you're using to be thinking about peer to peer programming of a wide variety of actors. Reach provides automatic formal verification that makes it so that you won't make mistakes. Or rather, if you do make mistakes, then Reach will catch you and make sure that those mistakes don't enter the final version of your program and put you and your assets, and your users assets at risk. Reach is blockchain agnostic, which means that we allow you to go above the tribalism that tends to exist in the blockchain world, and it makes it so that you can basically have diversification with regards to your expertise. Because if you go learn a low level tool and you learn that low level tool and the platform doesn't take off, then you just spent a lot of time and investment to gain some expensive skills that are not useful. But if you learn reach, then you'll be able to apply CTO whatever blockchain ends up being popular. Now finally, not only does reach have a javascript syntax for writing your reach program, but we actually provide a JavaScript based interface for interacting with your program. And this interface basically makes it so that reach integrates with any existing JavaScript library. If you look at our tutorial, we walk through building an automated test suite JavaScript program and then we take the exact same JavaScript program, sorry, the exact same reach program, the exact same JavaScript program, and then we just add some stuff around it to turn it not from an automated program, but turn into an interactive command line based one. And then we take that program and we adapt that to turn it into a web based program. And at no point in the transition from automated CTO interactive to web based do we have to introducing any new blockchain or reach ideas. Weve just applying normal JavaScript techniques. So our goal with Reach has been to make it so that any existing full stack developer has the expertise to get into the exciting world of blockchain and learn about how they can improve the programs and the features that their apps are providing by removing those trusted centralized parties, whether those trusted decentralized parties are providing payments or providing databases. If you want to get started with Reach then you should join our discord or read our documentation. Our documentation is at Docs Reach Sh and there you'll find a link to our discord server as well. When you join the discord server, be sure to introduce yourself as coming from Comp 42 and there will be lots of people there who will be excited to talk to you about why you're interested in blockchain and what you want to do with it. And when you go to our documentation, you'll see a very slow introductory tutorial that walks through the basic ideas of blockchain, the basic ideas of building and deploying and testing a reach program. If you try to learn blockchain programming some other way, you're going to have to learn low level tools. You're going to have to learn about exactly how to build a private test network for whatever chain you decide to use. You'll have to decide what chain to use. There's a lot of things that you need to do, but with Reach we've designed something that is a completely dockerized program where you're going to download a very small shell script and that is going to manage creating dev networks for you, compiling your programs, building test suites, integrating with existing tools like Reach, sorry, lines react or view and whatnot. So we're really excited to have you come and try out reach and start your journey into breaking into blockchain development. And I can't wait to talk to you on our discord. Thanks so much for your time today. Have a great day.