I'm good, we're coming off of, freshly off of a workshop that we had on Wednesday and Thursday. And so to be honest, you know, Meredith and I have been on camera a lot this week. Yeah. And the week's leading up, because we do some, we pre-record some of our sessions too. So this is gonna be, I think, just kind of an informal chat reflection about how the workshop went and things that we're looking forward to, stuff that even things that we saw that were maybe, I have some things from the Discord chat that got brought up that I thought were really kind of cool and yeah, we're just gonna be a little bit informal in reflection. Before we even dig into that, if folks didn't know we are, the workshop we just came off of is this one on our event calendar. So it was Wednesday and Thursday. It was a combined Domain and One Zone WordPress multi-site two-day workshop. So day one was focused on Domain and One Zone, day two on WordPress multi-site. We've never done that before in that format. And in fact, it occurred to me and that, you know, we only recently started doing WordPress multi-site workshops at all. We did them in partnership. Yeah, I feel like this was number two. I think it was technically three, but it was the second 101. So we did two with Tom Woodward involved, a 101 and a 201. And this is the first time we've done one, just the core reclaim team basically. So, and so that was kind of big for us because, you know, we do workshops basically at the minimum once a year. Sometimes we do, often we do them twice a year if there's demand and time and interest and things.  We reexamine the topics every time. There's always slightly different sessions. And also, of course, the actual, you know, our best practices and advice changes every time, of course, too, at least slightly. But I think as a company, you know, Domain and One's own workshops have been a thing for at least, you know, I went to one as a customer in like 2018, I'm sure that wasn't the first one. So. Yeah, that was the first one. That was actually the first one we ran in Fredericksburg. We started with two in town, 2018 and 2019. And then, of course, 2020 didn't never happen, but the last couple of years we've been doing remote workshops. And I think we've got the like routine down. Yeah. Preparing and getting all the sessions set up and everything. We're really falling into a rhythm with them in a way that makes them, I'll just say, significantly less stressful for us as a team, which is great because it means we can be more present on the day of the workshop in the Discord answering people's questions, which I think is huge. We've had, I guess I haven't had the question recently, but I've had the question before of like, hey, like, why do you guys prerecord any of these? You know, if we're all watching them together on YouTube and stuff like that. And the answer is we prerecord some of them because it, A, I mean, it's just, it would be a heck of a day to be honest with you. And it B, it means it kind of feels like a ghost town in terms of discussion. I mean, of course, the participants discuss and that's awesome in Discord. But if we're all tied up with producing live video the entire day, then when questions come up that we may be able to answer, we're not in there prepared to answer basically. And it just, it doesn't really, I don't think it works very well. And I think this format that, you know, sort of got pioneered in OER by Domains 21. That was sort of like the earliest version of the format that we're using. We'll talk about the format a little bit more, but it works so well for, hey, this is a remote workshop that people can attend live and discuss and it feels lively and not just like, I'm watching a video today, you know? But also it's really accessible and people don't need to be there during if they can't. We have plenty of people who say, oh, I could make it for two sessions but the rest of the day I can't, sorry. And we go, well, you know, if you want, they're all available as recordings as soon as they're done. It's not, you have to wait a week for us to upload them. They're, as soon as it's over, you could watch it again if you wanted to. Each individual session. And I really think that works well for people. And I think it's a realistic compromise between an event and it feels exciting and meeting people where there are, which is that not everyone has two days to effectively not do any of their normal work duties, yeah, absolutely. Yeah, and that brings up the question, how do we actually put on the workshop and how are we able to make it accessible almost immediately after the session finishes? Yeah, so we'll go through some tools that we use here. Some of this is stuff we've of course talked before but I think it's good, you know, I always think of these Friday streams as our off the cuff informal, we'll call it vlogging, I guess, right? Like it's a video version of this for us as a team in some ways to kind of just track the time and say like this is what we're doing this week, this is what we're doing this month or whatever so we can look back on these. So as of, you know, February of 2024, this is how we do a paid workshop like this. So we now have this wonderful event calendar website and I say wonderful because it saves us a lot of time and headache and setup. But basically we have this event calendar website, we use it for all kinds of things. So we of course post an event about the workshop to the calendar and then obviously tickets aren't for sale anymore because, you know, it's past but when they are for sale, they're down here, people can buy them. I had, I'll just say we're using the event calendar plugin and a Stripe integration to collect payment and I had zero, I heard from nobody about having trouble buying tickets which is awesome and honestly not a given with like institutional credit cards and stuff. Sometimes that stuff can be kind of weird. So that was great, highly recommend. And that was awesome because then what results in that is we get this handy list, of course it's based on WordPress, we get this handy list of here's all your attendees and I've blurred the names out just, you know, you don't need other people's names on stream but we did have a few, we did, it looks like have folks that put like the wrong payment information in so some folks are listed twice but it's basically 32 people minus one, two, three missed payments. So we had 29 attendees across both days. And this is great because not only can we get information, you know, their name and email from here, the event calendar also lets us ask questions about them so we can say like what institution are you from and what's your Discord username because we use Discord for discussion. So this is just great. We had some folks didn't know their username at sign up maybe because they hadn't used Discord before. It wasn't a required field so, you know, but for the most folks we had this ahead of time and it made things really easy to set up. We also are able to use this tool to email attendees and let them know about what's going on. So this is just honestly, it was a big time saver for us this time around. But then we use this watch site. So this watch site is a couple different things. It's again, sprung out of OER by domains 21 and there's some things that we're doing differently here from that time but, you know, basically we have a different WordPress site that we host that has all of the session information that we enter and that's using a plugin called Advanced Custom Fields and some work that Tom Woodward set up for us. So we basically have a special post type that all the sessions are and then these sites, we basically, I made them so that we can basically give them a few pieces of information as like PHP variables. So basically we just type into a text file the category of what posts and what Discord channel it should pull in is pretty much what we do. So these sites are really easy for us to maintain and keep organized. So all of the sessions go into here and each session links to a YouTube video which we'll load here and it keeps track of the time. So when the session is actually live, oh my God, my cat decided to jump on my lap. Just went to the vet this morning so she is like very spooked. Oh no. But anyway, so the sessions are live on YouTube. So basically we pre-record some of them and we use YouTube's Premiere feature so that they can air at a certain time and everyone can watch together. But then as soon as they're done, they're available as a recording at the same link. And all of those features are really handy, right? The fact that we can all watch together live is great instead of like releasing the video and people can be at different points, that's not very good for discussion. You want when it's the session time, when it's live, you want to know that everyone's watching at the same place in the video or at least can be watching at the same place. So that way when people are typing in Discord, you all know what we're talking about basically. So that's huge and honestly something that I haven't, there's not a lot of other ways to do that kind of thing. We've been using YouTube Premieres for a long time now on this stuff and they're just great and rock solid. I can't say we've ever had an issue with the YouTube Premiere. And then again, the fact that they're available at the same link immediately after is key for folks to be able to watch on their own time. Live streams are similar, right? So for our live sessions, they go in as this was a live session and now that they're recorded after the fact, you really can't tell the difference honestly, but these sessions also are available immediately after for folks to watch too. So it's super nice. And we can put basic descriptions in this site, title, things like that. Finally, the last component of this website is this Discord embed. And we do this so that folks can have like a one page experience of the workshop. So we can just say, go to this URL and there's your workshop basically. And that's super handy. I will say we use something called widget bot, which is like a, it's a bot and an integration with Discord. And it works really well except when they have outages. And I will say this morning, they're having an outage it seems. I can tell because we also use this on ReclaimTV if folks are watching live and it's also not working over there for me right now. Maybe it's my browser too, it's possible. But I'm getting this error on our watch site too. And they have outages once in a while. It's a free service. And I think one thing I'd like to look in the future is like if they offer paid support of any kind because we use it enough now that I think it's kind of a key part of our infrastructure. As far as these workshops go, obviously, infrastructure is a little bit of a loaded term at a hosting company. Maybe I shouldn't use that word. It's an important tool that we use for our workshops. And it's one of the only ones that we don't have the ability to like replace with a self-hosted version. Most of the stuff we're using is self-hosted except for, of course, YouTube. But we have an alternative of that. We have PeerTube and we could use it. It would just be way less convenient because of the premiers is not a feature that PeerTube has. So that's one other thing, but it's really nice when it's working because folks can just message right inside of here and they don't even have to have the Discord app open or even installed, which is, I think, really key because we like Discord here a lot for the community building we can build inside of it, but it's a compromise in the sense that it is a walled garden. You have to get a Discord account. They're free, but you have to have one. And that gets really complicated for a paid workshop, right? Because we have folks that say like, well, I don't want to install Discord. We go like, look, A, you don't have to if you don't want to. But B, you can participate without installing anything. You can just make an account and log in right here and you'll be good to go. And I think that makes a big difference for us. Absolutely. And obviously we could use some other live chat thing, but Discord has so many benefits because we can keep the conversation going after the workshop. And I think one thing that we're starting to see a couple of years on, this is our second year of having a EdTech Discord. And we're starting to see more organic conversations and questions and answers happening in there. And it's becoming, I think, a really valuable space so we can use that for the workshop too. And that all synergizes, you know? So do you want to talk a little bit about how we approach having the separate channel for the paid workshop for both WordPress multi-site and domains? Because I think, because we within the Discord setup we have WordPress multi-site and domain of one's own separate channels. And we wanted like, I think it's kind of interesting to talk through like how we wanted to make sure that the workshop attendees had their own channel to talk in outside of the full community while the sessions were running. That's kind of another thing that Discord makes very simple for us and not something we could do if we were using just like YouTube's chat or whatever. So, or not easily. So, well, no, not really at all. So yeah, so we make private channels for each paid workshop. Now, we do free events too for like our flux courses are all free. But, and those also get a channel. But for paid events, we simply switch the channel over to private and Discord, which is pretty easy to do. Actually, like it's literally just a toggle in if you like, if you run a Discord server you can go to the permissions on a channel and switch it to private. And then from there, you can either add roles because Discord has a whole role system or you can just add individual people to the channel and say, these people get access. In the past, when we had a subscription for a whole year of events, we did use the roles to manage that and make that easy to do. But honestly, now with these one-off events and single attendees, it's really easy to just add individual people. And we just kind of do it on the fly. So basically two days before the workshop I went through our event list of the folks that had given us Discord usernames and added them, which, you know, took me like five minutes. And then, but we of course had a lot of people who joined the day of or even in the middle of the day. So, but that was pretty simple. We just told them an email like, look, if you join, you don't see this channel reply to this email or just say something to the Discord, just speak up and say, hey, can I get added to the channel? And we had, you know, I think like four or five people that did that and that was, that covered everybody basically. So we, you know, these are paid workshops and what we're asking for payment is for our time in preparing the workshop, right? We don't wanna put make the experience of attending the workshop worse because it's paid and therefore not something everyone can attend. And we've talked a lot about that. I think we all have a lot of feelings at the company. Like, I don't know, Meredith, you've had this experience, but I've definitely had the experience with like other online workshops from other places where it's like, all right, I've paid a lot of money for this and like the thing we're using to watch it or participate sucks. Like barely works or it's hard to use.  Did you know Adobe had a video conferencing solution? I didn't until that day. I don't even know if it exists anymore to be honest with you, but it's not good. But so that very much influences this and that's why we wanna use things like YouTube and Discord because A, you know, they're relatively, they work, they do what we need to do, but B, we think they're gonna be good experiences. Like it'll be a good chat experience that has things like threads and replies and emoji reactions, which, you know, in like a professional context sounds silly, but like I think a really important communication tools, especially like emoji reactions, you might be like, who cares about that? Honestly, that's how people communicate. It's how I communicate at least, you know, in some small way and it contributes hugely to make this feel like something that can be fun, I think. Absolutely. And then on the YouTube side, right? Like it's just the world's biggest video platform. So we're really big into self-hostable stuff and we use those things too, right? Like right now we're broadcasting to both YouTube and our own cast server on Reclaim TV and then the video will be archived at PeerTube. That is all great. I love that stuff. There are probably few companies in the world that appreciate the value of that more than we do, obviously. But on the other hand, you know, Google knows how to serve a video globally. And I think that's really important when we're talking about paid stuff. It needs to work. And also we wanna make sure it's accessible in ways that we may not think of too. Like, you know, YouTube has automatic, pretty good live captioning, right? That's awesome and could be important for some of our attendees. It's also really easy to watch a YouTube video on like a TV, right? Because pretty much everything that supports internet video will have a YouTube app. So in our videos apply there too, right? So you can literally like click on one of our videos and it'll break out to the YouTube website and you could use a Chromecast or AirPlay or something to put it on your TV. So all of that I think is really important because we want it to be a good experience, you know? Yeah, absolutely. I think we did a really good job making it seem like a synchronous event as well. Like you were saying that people didn't, some people couldn't attend the full time. So having that option to watch separately, I think is really helpful in that capacity from there. Yeah, so I'm really happy with that foundation. I think there are things that we want to improve on, of course, like there are changes I want to make to the watch site. Like I've seen more recent OER iterations where they have the ability to view the watch, the playlist of videos, the schedule in a vertical format with like a button that would show you the whole schedule at once. I think that would be great. Scrolling horizontally makes a lot of sense in terms of making sure there's enough space for the videos and stuff. But I think if you want to jump around and see the whole day at once, that could be something that maybe we could borrow from Michael Branson Smith's work on that version of this player. I want to, I think it would be good to have a ability to hide the Discord chat actually because while it's great, if you are using the Discord app, it's just a duplicate, right? So I want to make a toggle for that. And I have done that on Reclaim TV. I shouldn't say I've done that. Sort of the way I hacked Discord into Reclaim TV owncast has that built in basically. So I want to do something similar and personally I've been kind of over the last year starting to get a little bit more familiar with like real basic terrible JavaScript stuff. Like I'm bad, I'm very bad at this, but having a basic understanding of how this stuff works and then spending some time with it and using things like chat GPT to fix my code up, actually I can get pretty far with bad skills. So I think there are some things that would be nice to have that we could work on over the summer for a potential fall workshop. But honestly, all those things are I think relatively minor. And I'm really happy with this format and I'm interested in seeing how we can expand it out too. Like maybe in the future, we can have other types of interaction. So more than just Discord, like what if we had like use something like a collaborative whiteboard tool and asked participants to add to the whiteboard. This is a little bit like methodology in search of a problem, but I do think it would be fun to have more interaction methods throughout the day. So that's something we can always consider. Of course, for us from a planning perspective, we also are never sure how many people are gonna be able to attend. So it's a balance of like, well, if we make a session depend on questions and only five people are able to watch live, that's not great, you know. Yeah, absolutely. Normally, I would say looking at the numbers yesterday, we had usually between 15 and 20 people watching live. So that was great. But everyone interacts with this stuff differently. So we didn't hear from every single one of those people in Discord. We heard from most of them, but not every single one, right? So people attended these things differently. And again, I think that's a great side effect. It would be way more tiring and grueling if we asked folks to be in a five hour Zoom call with their cameras on or something. Yeah, exactly. So I think this, I'm still really happy with this format and I don't see us deviating from it anytime soon, but maybe we can keep building on it. Absolutely. The last thing that we use in terms of making all this stuff happen is we heavily use StreamYard, which we're using right now to produce this video. And I am trying to think, it would be unwise for me to try to show you what StreamYard looks like while we're in it. But you know what? I can, we're gonna find out. I'm gonna open it in a different browser. We're gonna... I was gonna say I can take a screenshot of us and we can share that too. I'm gonna open it in a different browser here and I won't actually, my like camera or microphone or anything to that one. And that may work. So let me see here. Yeah. Ooh, yeah, of course that was gonna happen. Maybe I can turn that off. Well, nope. We're just gonna be brief with it. But basically the StreamYard here is our live production tool. It's a paid tool, honest. I don't know. I think it's between like 20 and 30 bucks a month that we're paying for it, which is honestly for the value we get out of it. It's great. Like that is so worth it. But basically it means that Meredith and I can join in to a live session here and just kind of we can make sessions ahead of time and they are kind of like a cloud hosted version of OBS, which we've talked a lot about OBS and I love it and it can do a lot more things than StreamYard can do in many cases at higher quality. But StreamYard makes this stuff simple to set up and use and that is key when we're talking about a whole team trying to do this thing. But basically StreamYard lets us pick different layouts here and I'll switch layouts around and do kinds of all kinds of things with it. But and that's about all I'm gonna do with showing StreamYard because it's pretty dizzying to look at the infinite hall of mirrors thing. But it's a live production tool. We can make all of our sessions that are live in there and it's super nice because it'll actually go and make the live stream on YouTube for us, which is really cool. And then we also use it for our pre-recorded sessions too, we just go in there, we record. StreamYard keeps a copy of the recording. So when we're ready to upload it to YouTube and air it as a premiere, we just download it. Trim it if it needs to be trimmed. Usually not though, we're getting pretty good. I had to edit like a few seconds out of one of ours because I accidentally closed the StreamYard window while Pilot and I were recording. Oh no! But other than that, I think we're getting pretty good at this in terms of being efficient with it. But yeah, StreamYard is a key tool to make this. Can you imagine if we were doing these and we had like on Wednesday, we had three live sessions and if we had to rely on someone's home internet connection and OBS setup, one person, let's say it's me. I hope my internet connection was good all day. It usually is. Yeah. But it's a pain of it. You really don't wanna mess it up, right? Yeah, you don't wanna have that. One point of failure. And even with yesterday, I mean, not that AT&T has home network, but when that whole situation was going on, if we were relying on someone who was using cellular data and was on AT&T, clearly couldn't, or you were even saying you were having weirdness with Slack? I was having weirdness with Slack for a little bit, which it's probably completely unrelated to the AT&T thing, but what I was saying, I was speculating with Jim, I was like maybe like AWS is having some kind of outage because you see that a lot when a big cloud provider has like one region of their data centers out, you'll see like weird patchworks of websites not working. I don't think that's what that was in this case. We would have heard news about, you kinda hear about every large AWS outage, but I don't know what it was. I'm guessing someone at my local ISP, which the ISP, I live in a very small town and the ISP is like headquartered like 15 minutes away from where I live. So it's like, when I call, I love them because I've had to call them for support once and I was like, yeah, I'm having this issue and they're like, when can we come out? And I was like, what, when are your techs available?  That's amazing. These are the best. So anyway, side to side tangent, but yeah, you know, obviously it was Slack, but it could have been my whole internet connection, right? Like who knows? So, and it's really great to know that we can, we're not, we don't have a single point of failure on this stuff and we're still gonna, I still like to use OBS for certain things and I kinda wanna bring it back in the rotation for some of these Friday streams that are, low risk because I think it would be kind of cool to do some things we can't do in stream, like virtual green screen stuff and things like that. I can actually run on my Windows desktop because I have an Nvidia card, it does like really good virtual green screen stuff. And I was like, have be kind of cool to have the team and not be in boxes for once, you know? Is that essential? No, but it's fun. Yeah, absolutely. Yeah, and it's nice because we share a login through our password manager anywhere I think you don't really even need like separate username and passwords. So like, if it's a reclaim based stream and like the live stream, like I was with pilot yesterday while she's talking to Laura at University of New England, I was in the background managing, like producing the live stream while pilot was able to speak with Laura but we both were signed in so we had like the privileges to like make changes if needed or anything like that. So super, super fun. Yeah, it's so nice for us to have a concept of like a host and a producer and be able to even on the fly. Like if for some reason you weren't feeling good, it's like, all right, I'll just jump in and do it, you know? Any of us can. Yeah, honestly, I was aware of StreamYard before I worked at Reclaim but I'd never really used it. And I think it's a no-brainer if you're working on a team that does anything with video. Totally. I would be... Yeah, we occasionally did stuff with video at my last job and usually that was sort of just like my thing anyway so it kind of made sense that it was OBS but the usability of StreamYard and how quickly you can show someone else how to use it too is just, you can't beat it. It's so good. Yeah, so that was the sort of the technical things. I'm trying to think of any other pieces of technology we're using for the...  I think we have some Canva lovers. I haven't used Canva for slides yet but that's not maybe the most exciting thing, but... Yeah, I definitely use Canva for mine. You can definitely see a running theme because I like the one template that I set up for a workshop maybe one or two ago and so I continue using those. And it makes it really easy. Like I just download the slides as a PDF and then when it's in StreamYard you can like click through each image so you don't have to like worry about sharing like a Google slide or anything like that which is really, really helpful. Yeah, it's a good point. StreamYard lets you upload PDFs and I think PowerPoint files directly into the interface which is super cool because you don't actually have to use screen sharing then which is, you know, screen sharing works fine but it's kind of nice, especially if you're on like a single monitor or something like that. It's just really handy. Yeah, I used, I made one slide deck. I think this is actually the first time I made a slide deck for one of these workshops. I am sort of, I'm slide adverse. I don't have a problem with slides but it takes me forever to make them. I don't know why. Anyway, so, and I did the same thing. I uploaded minus PDFs. In my case, I used this tool called Brilliant. It's okay, I wouldn't recommend it. No. Use Canva, use Google Slides. I also really like slides.com which makes slides that you can actually self host as websites. So that's really cool as you can export them as an HTML file when you're done and just throw them in your C panel and now you've got a nice web native slide, which is cool. Yeah, that's awesome. Yeah. Yeah, so that's kind of the technical, I think, overview. The last thing I think we should give a little time to is just sort of themes we saw and upcoming things for Domain and One's Own or WordPress Multi-Site. And I do have a couple ideas here. I sprung this idea on Meredith so Meredith, don't feel bad of you. No, it's okay. But one thing I noticed a lot of people talking about in the WordPress Multi-Site yesterday was there was actually kind of a lot of discussion about policy and purpose. We did have a whole session related to that, so that does make sense. But it does feel like it resonated with folks or at least a subset of folks in terms of like, what are we, and what I mean by that is it was a through line on all of the discussion in some way, right? Right from the beginning of the day we had folks talking about like, oh yeah, it would be good if we had policy or I guess this session was at the end of the day, but it was brought up all day on like how long sites should stick around and what is an active and an inactive site? And we kind of, and I think many different sessions actually made the argument of like, look, you just kind of have to define it, right? And you have to put it somewhere and then you have to point to it. And I know that's not like mind blowing or anything, but here's what other schools are doing. Use, you know, inform yourself based on what they did. And it's gonna make your life easier rather than saying like, well, we'll figure out what an inactive site is 10 years into the multi-site, you know? Yeah. And I think that's been a running theme I've seen with a lot of people outside of the workshops too, like the work you were doing with UMW blogs and like archiving all of that work and VCU rampages is doing that sort of thing right now too, like trying to figure out like what makes the most sense on existing multi-sites to try to keep those there. And it's definitely, I find it difficult to try to define itself because it's not as black and white as like technical things would be, like how to troubleshoot something or how you would approach a specific scenario. So I think being mindful of like in continuing to talk through that whole process of the policies you wanna set for the multi-site is really helpful too. And I try to remember like, I think something you said about, I lost a train, but there was one piece that you said and you're in the policy session that I thought was really cool, but I will put that in the chat too. Yeah, so Tom in Discord just said, starting with rules people understand and can see is much easier than applying stuff retroactively. Yep, it just is. And also I think it's also never too late, right? Most of the people, I don't think anyone we had in the workshop yesterday was like, well, I don't know for sure. There's actually a couple of people who sounded like they were like going to maybe start a new multi-site, but most of the people were veterans of this stuff or at least in some way or we're sort of kind of new to the project but they were coming to a multi-site that's been around for at least a few years. Right. It's not, you know, start now. Like it doesn't, it's not a big deal. I think in my opinion, obviously you need to get lots of, you wanna get feedback on things, but having that stuff spelled out in my experience is way more comforting to folks than not, right? Like it's easy to say like, well, we can't put a date on things or a policy on things cause then people will be afraid their stuff's gonna go away.  If you put a policy on it, people are gonna go, well, I know what to expect now. And that's at least my experience with honestly that applies pretty broadly to almost any IT project at a school. Yeah. And it was kind of cool that like we had some folks that were talking about like, oh yeah, I've got sites on our multi-site from 2007 and it's really rough cause we don't know what to do about it. And I was like, well, yeah, like that is hard to deal with, but also so cool of a problem to have in my opinion. And obviously I'm, you know, have the bias of, I think it's long live web projects are great. I think that's one of the best things about the web is that things can last a long time, but they don't always, obviously. And I mentioned, I was in there, I was like, think of how many services like a given school has started and retired in that time. Like from 2007, you know, I used to work at St. Edward College. I can tell you from two, I was a student from 2010 to 2014. And in the time from 2007 to today, they have gone through three email providers. You know, like that's wild. But WordPress lived all of them. Obviously this is a different school we were talking about, not St. Edward. But, you know, I wouldn't be surprised if it was similar for them, you know? So I think that's awesome, honestly. And so setting policy around, well, you know, when do sites need to go away? And usually my plainest recommendation is like, how about when no admins on file have email addresses? Like that's, you know, kind of what I like to go with as a starting point, but you can go more from there. That was something that was through, you know, throughout the whole thing. On the domain of one's own day, honestly, there was a lot of different things that we could pull at. The domain of one's own session tends to be a lot more about, you know, technical, like how to do things. And the WordPress multi-site tends, at least what we focus on tends to be how to think about things and get started with things. Because the reality of administering WordPress multi-site, at least from our perspective, the first folks we work with is most people don't need much other than like, you know, some guidance on how to set policies and then we can kind of help them with all the technical stuff and most things they'll need to learn, they can learn pretty quickly. And anything beyond that, that's what they're paying us for, right? Right. Whereas domain of one's own is, there's a lot more technical possibilities, right? C-Panel can do all of these different things, all kinds of applications, backups, all these things. But it was really cool to see so much thought around, it's the thing that attracted me to domain of one's own before I, well before I even worked at Reclaim is so many admins thinking critically about, you know, what domain of one's own means at their institution in terms of digital literacy and critical practice. And like I love that stuff, domain of one's own always, I think draws that type of, often draws that type of admin as someone who's like, got a technical foundation but wants to help, you know, explain these things to their users or give students the opportunity to explore these tools. And I find it really energizing every time we do a workshop, when I see people talking about that stuff. So it's super cool. Yeah. Yeah, I thought overall like the security mindset, we did a security stream with Noah to talk through some of like the things that are on his brain with security. And I think Reclaim as a whole for the last couple of years, like I wanna say since like middle of last year, we've been in a security mindset for sure to like try to make sure our servers are up to date and just taking on some more projects and getting specifically certified and RAM compliance and things like that. So I think that's been a running topic for the team. So I always enjoy watching those sort of streams too. Yeah, we got Noah on for a session, kind of a security ask slash tell all. And it was really great. I love when we can get as much of the team at Reclaim involved and my cat is just wants to be on the desk today. And we don't always have the opportunity to get infrastructure involved. And frankly, usually when we do, they're kind of like, I don't know. I was like, no, it's cool.  And Noah was game. But yeah, so I always love that. And that I think we definitely wanna continue sessions like that going forward. And it was even cool because we had recently, about a month ago, done a stream. Noah and I did one on like open source security related tools that we're using. And so it was kind of nice to be able to point back to that and say like, hey, we talked through this thing in more detail if you wanna learn about Wazoo and a Sim that you could self host. And it's like, we're not gonna go through all of that in this session. That's not really something you have to worry about because we are doing that for you. But here's what we're using. And if you're curious, here's more info. And I like that. I thought that was a really great session. Definitely wanna do that more. Yeah. And it was, it's, yeah, I'm really, I'm really excited to, we have some ideas internally about things that places we wanna take Domino One's own and WordPress multi-site at, you know, at Reclaim and some stuff that I can just talk about like vaguely, like, I think it would be great to keep pushing on some of the work that they're building on. Amanda did a lot of work for last year's WordPress multi-site to build out specific multi-site focused knowledge-based articles. And that's really great. And I think we wanna keep building on that because we are pretty good and comfortable with WordPress hosting, but we don't have a lot of like, out there public recommendations for processes. We're starting to do that, right? These workshops are that and that the knowledge base is. But I think we wanna keep building on that and trying to help, you know, new multi-site folks start with like an experience that we can say, like, here's what we'd recommend and you can deviate from any of this, but here's the Reclaim multi-site experience, you know? Cause we don't really have a specific set of that right now. We have certain things, right? We know how we do single sign-on. We can tell folks how that works. We do have a couple plugins, but I think we wanna keep building things there. And that is stuff that we do kind of have for Domain of One's Own that it would be cool to see for multi-site. And kind of similarly for Domain of One's Own, you know, the work that Tom did with the dashboard plugin and I've pushed out to quite a few schools now and we are still working on a global rollout so every single school has it. I will say, we probably have more than half at this point that I've just manually installed it, but the global rollout of that plugin is gonna be, I think, really interesting because it's gonna allow us to do more work like that a lot faster in the future. Basically, we have some foundation laying to do to be able to push out custom code to these particular WordPress, not multi-sites, but WordPress sites that power Domain of One's Own in a good and secure and safe way. And we're working through it right now, but once we do that, I'm really hoping to do more stuff like that dashboard plugin, you know, more reports, more things like that. We already do, you know, in the last couple years do a lot more like managed updates of those WordPress sites for admins. They don't have to think about it, but this would be building on that work even more. So. Yeah, absolutely. Oh, someone just had to chat a little bit. Yeah, so Ed mentioned, you know, it's a differentiator between you and that other larger organization that hosts multi-sites for campuses.  Like, I think it's cool that they have a page that say like, these are the plugins that we have. Now the downside is those are the only plugins I don't think that's strictly true, but it's mostly what you can get access to over there. And, you know, they do a lot of development and stuff that we are, you know, we're there at a scale that we're not at in terms of like literal like plugin developer developers and stuff like that. But I do think we can curate things for folks and we're doing some of that and I wanna keep pushing on that for sure. Absolutely. I look at their list of plugins too. It's typically good, but a lot of them are proprietary to them. So, I don't think so. Oh, okay. Yeah. Awesome.  It's kind of how it goes, but we'll have, you know, spring and summer to kind of build things towards it. I always like to have a lot of our, especially Domain of One's own related projects, but now we're personal site too. I like to have as deadlines around the workshop because it's sort of a natural place to be like, oh, this is a new thing that we can talk about and stuff like that. So, there's a lot of changes happening at Reclaim in terms of, you know, capabilities we have and, you know, server migrations are huge right now for us getting off of CentOS. And a lot of those things will be very different by the time the next workshop is around, so. Yeah, absolutely. Yeah, cool. Awesome. Yeah, I really enjoyed the last couple of days with the workshops. It's always really fun to see the new faces of the admins that have come on since the last workshop too. So, I always like to see that and see how they're starting, I think, through their project. So, that was really cool. Mm-hmm. Well, I think with that, we're gonna sign off unless you have anything else, Meredith. No, that was it. That was a good recap. Great. Thanks for joining me. Thanks for everyone who watched and we'll see you next time. Yeah, see y'all.


Hello, everyone. I'm here to present KVM, a complete formal semantics of the Ethereum virtual machine. These are the authors on this paper. I am the first author here, Everett Hildenbrandt. This was a joint work between people at the University of Illinois, runtime verification, Cornell Tech, and East China Normal University. So, yeah, big long author list. A lot of people here helped out immensely with all the tooling and fixing issues in K as we found them, and then a lot of people contributed directly as well, and I figure we should acknowledge everyone who helped out with the tooling because that's important as much as the direct contributions. Here's the overview of my presentation. First, I'm going to walk through a little bit about the K framework. Then I'm going to talk about the Ethereum virtual machine. Then I will talk about current uses of KVM and future work that we have. Here are some repositories that you might be interested in after the presentation. First one is KVM itself. The second one is K itself. Then runtime verification's website. Then our verified smart contracts repository, where we put all our open source verified smart contract code. You can use that as a template for verifying your own smart contracts if you're interested. So first, K framework. The vision is language independence. So we want to separate the development of PL software into two orthogonal tasks. The first one is building the programming language. So you have a programming language expert build a rigorous definition of the programming language, and they can incorporate all their knowledge that they have of programming languages in doing this. Completely separate is the tooling around the language. It's not completely separate. You want it to know about the language itself. For instance, people might make a parser for C, they might make a parser for Java, and there's a lot of similarities between them. So you kind of want one parser that you can instantiate to all the languages. Same with your interpreter, debugger, compiler, model checker, and verification engine. So the idea of K is we separate these two tasks into two separate tasks, and then we can focus on building the tooling around all the different languages. And as people need, they can build the actual languages that they need. This has worked pretty well so far. Here's kind of a visual representation of the same concept. Here you have your formal language definition, and from that we derive the interpreter, derive the parser, derive the test case generation, deductive program verifier. So these two right here, the compiler and test case generation, are kind of more in the vision phase right now, and some of these actually exist. So there's kind of already a lot of tooling that we have around all these languages that we have semantics for. Here's some examples of some of the languages we have semantics for, and their primary usage that we have for those semantics. The first one is C, where one of the primary uses we have of that is detecting undefined behavior. We have the semantics of Java, where we can detect RACI code. We have the semantics of EVM, where we can verify smart contracts, the semantics of LLVM for doing compiler validation, the semantics of JavaScript for finding disagreements between JavaScript engines, and the semantics of P4, which is the software-defined network data layer verification. I included that one in there to show that you don't necessarily have to stick to just programming languages when defining the semantics of things. Just arbitrary transition systems are also good. And there's many others, less used semantics, but you can go to our GitHub organization to see all the ones we maintain, and then there's several that other organizations maintain as well. Okay, so let's get right into some of the details about K. So we build concrete syntax of the programming language using this EBNF style. Here we're declaring a new type or sort, as I'll call it, called XP, where we say that all integers and all identifiers, which are just essentially lowercase names, are of type expression, but also we can build expressions as multiplications of expressions or as additions of expressions. And here, notice that this right arrow here means that plus is looser binding than the multiplication, so then we can parse expressions correctly. And here also, we say that you can put expressions in brackets using parentheses, and this bracket annotation basically says that we don't actually care about the parentheses. The statements of our programming languages are pretty simple. We have assignment, and we have sequencing, so we can do an expression, a statement followed by another statement, and we can return. So now we can, just from this grammar right here, we can correctly parse a program like this. A, which is an identifier, is equal to 3 times 2. B is equal to 2 times A plus 5, return B. So we're not actually doing anything with this program yet, we're just able to parse it with this part of the grammar right here. And notice also here I don't have to put any extra parentheses because I said that the plus is looser binding than the times. You have to tell K a little bit about the structure of your state for your programming language. To do that, we declare what's called a configuration. The configuration here has three cells, the K cell, which will contain the initial parsed program, as indicated by this dollar sign PGM. The environment cell contains bindings of all the variable names that show up in the program to their store locations, and the store actually contains the values that the variables are bound to. So here's some example rules, which are transitions in this transition system. Here, for example, is variable lookup. Here, if at the front of the K cell, we have some identifier. So here this would happen if we were trying to execute this statement right here. Oh no, not this statement because there's no identifiers on the right-hand side, but this statement right here, when we tried to essentially execute this A right here, what will happen is A will be pulled out to the front of the K cell using some K magic that I haven't gone over yet, and I won't go over in this presentation, so you can see the tutorial for that. Once the identifier is at the front of the K cell, we look up in the environment where the correct store location for that variable is, and in the store, we then look up what the value associated to it is. What I'm not showing you here is the negative rule, which says what if X is not in the environment, or what if SX is not in the store, but you can make a rule for that as well. Basically, what we do is if we're trying to look up a variable, we just replace it with its actual value. So here we've grabbed the value from the store and we replaced it right there. Similarly, for assignment, instead of lookup, we have some variable that we're assigning to here and we're assigning some integer to it specifically. Notice we do the same thing, we go through the environment, we look up X, find the store location, and at that store location, we take the old value V and replace it with the new value I, which comes from here. Notice here there's two rewrite arrows right there. Here there was only one rewrite arrow, so there was only one small change to the overall state, but here the two rewrite arrows means that these two changes happen simultaneously to the state. So we consume this and replace it with nothing at the same time as updating the value in the store. I'm going to walk through an example execution to really drive this home. Here's our program, our initial program, A equals 3 times 2, B equals 2 times A plus 5, return B. Here is our initial configuration where I have set up some stuff here that would have to actually be set up, but I've just set it up. So A is pointing at store location 0, which is initially value 0, B is pointing at store location 1, which is initially value 0. Here's the entire program. The first thing that's going to happen is we're going to take this semicolon right here and we're going to turn it into this squiggly arrow, which means followed by mk. So basically that means we're focusing in on this part of the computation as opposed to right here where we're focusing on the whole computation, we're kind of just focusing on this part. Notice I've also simplified this 3 times 2 to just a 6, which is a step that would happen. But now if you inspect this, you can see that this x colon equals int matches this A colon equals 6. So then x is A, so we look up A in the environment and it's pointing at 0, so sx is now 0, and we look up 0 in the store and it's pointing at 0. So this v goes to 0, but we're going to replace it with this i right there, which is this 6. So in the next state, we will see this 0 is now a 6. And indeed there it is. And you'll also see that this goes away to nothing. Boom, it's nothing. Okay, so now we have the rest of the computation to deal with. And so I'm skipping a bunch of steps here, but basically what's going to happen is it's going to evaluate this sub-expression first. And to do that, it's going to first focus in on the 2, it's going to say the 2 is already evaluated, then it's going to focus on the A, and it's going to say the A is not yet evaluated. And that's what's happened here. The A is not evaluated, and it's followed by B with this hole in it marking, okay, when you do evaluate that A, put it back in that hole. But now we have an identifier at the front of the K cell, which is x. So once again, we say, okay, what is the store location associated with that A? This is the store location. Then we look at the store right there, and we get this 6. So in the next step, this will be replaced as per this rule with the 6. And we got the 6 right there. And then basically we're just going to plug this back into the hole here, which is stuff that K will do for you. And so we do that, and now we have B is equal to 2 times 6 plus 5, which simplifies out to B is equal to 17. And then we do the variable assignment rule again to now update this location in the store with 17. Okay, so that was kind of an example execution of K just to kind of step through and see, you know, the main thing to think about is this followed by arrow, but I just wanted to make sure that people are at least familiar with K syntax. Now I'm going to switch topics completely and talk about the Ethereum virtual machine just to give people an idea of what the challenges there are. And first I'm going to talk about what a blockchain is just the basics of what I need for this talk, basically. So a blockchain is an append-only ledger of transactions submitted by users. The transactions are usually just transferring some sort of value. So, you know, I might say I want to pay Party X some money and Party X might want to say they want to pay Party Y and then both those transactions get recorded in a sequence that eventually records that, you know, Party X has this much money and Party Y has that much money. So yeah, so like Bitcoin, for example, can do simple transfers of value and some simple logical things that are kind of hard-coded into Bitcoin. And then miners basically select which is the next pool, the next block of transactions to include on the blockchain and that's how we achieve consensus. So I'm not going to talk about consensus algorithms here. It's also an interesting talk of it, but it's not necessary for what we're talking about. What Ethereum adds on top of Bitcoin because most people are more familiar with Bitcoin or have heard of it than Ethereum is, first of all, it's a different currency. So there's, you know, a different exchange rate and different market. The accounts also have an associated storage and code which they can modify and read from in a transaction. So an account might be able to, when an account initiates a transaction, it's able to say I want to change my storage location three to have this value instead of this other value. So other accounts cannot modify or read storage locations other than, you know, just inspecting it externally because everyone has to know all parts of the blockchain state. Anyway, it's all public. So I can look at an account and say, like, oh, I can indeed see that it stores location three. It has the value four. But if I execute a transaction, unless I'm the owner of that account, I can't in the program directly read that value. So it's kind of this permissions thing that's going on there. The same with the code, only the account itself can kind of, you know, read the code to execute it. So you have to have that account's permissions to execute its code. Yeah. So the transactions can also have associated programs written in EVM, which is the Ethereum virtual machine.  Miners then, you know, because we now have these associated chunks of code with the Ethereum programs, the miners have to execute this transaction code to calculate the new world state afterwards. So I might send a transaction that says, in my storage location, update this value to this new value, and the miner needs to check, you know, okay, did the update actually happen, and then it needs to store that in memory because it might affect the results of a future transaction. So there's kind of this stateful component to it where the miners have to hold around all this extra state to decide whether future transactions are valid or not. So that's a big difference between Ethereum and, you know, a different system like Bitcoin is that you have these programs that sort of stateful component to them when they're executing, okay? Here's an example, EVM program. It's a very low-level bytecode. So it's a stack-based bytecode over 256-bit words. This program sums the number from 0 to 10, basically. So I picked this program because it already demonstrates kind of a lot of the pains of EVM itself. First of all, like, just looking at this, I don't see that it sums the numbers from 1 to 10 or from 0 to 10 in any way, shape, or form, but it does. So here what I'm doing is saying at memory location 0, store the value 0. So this is the current sum. At memory location 32, store the value 10. So you might ask, like, why don't you store it at location 1 instead of 32? And it's because EVM words are 256-bits wide, but when you use this opcode mstore and the kind of dual opcode mload, it just bytes instead of over words. So this actually ends up being a major pain. I'll talk about it a little bit later. Here's the marker for the beginning of the loop head, which is going to loop through. This is basically the condition of the loop. And then if the condition is false, then we jump to the end of the program, which is this is the marker for the end of the program, basically. And then here we are loading the current the current sum, we're going to add to the sum. We're adding them together, and we're storing it back in the sum. And then here we're loading the current counter and decrementing it by 1. Decrementing it by 1. Yeah. And then storing it again, basically. And then here we're jumping back up to the top of the loop. So notice here, we're not saying like jump, and then some string that says loop head, like a sensible IR that has labeled jumps instead we are pushing the value 10 and somehow you just have to know that this is at opcode position 10 based on the width of all these opcodes before it. So you might think initially oh, it's opcode position 6 because there's 1, 2, 3, 4, 5, 6. But that's not the case because these aren't all necessarily 1 byte wide. That's kind of one of the nuisances of the EVM is you have to calculate these jump positions manually or something. It's really kind of a nuisance. Then there's this other component of execution where if you submit a transaction that is infinite, just has an infinite loop, you could just say while true, add 1 or something. Then the miners would just sit there trying to execute it and figure out what the state update is because they need to know the state update to know if future transactions are valid. So we have to have a way to prevent this. So this is for DOS attacks. The question is that each opcode is going to cost some amount of gas to execute. So add costs 3 gas or something like that. And gas is convertible with Ether at an exchange rate decided upon at transaction time basically. Any unspent gas is refunded back to the original payer for the transaction and any spent gas goes to the miner. So it incentivizes the miners to kind of pick up transactions and execute them and actually include them in the blockchain. There's a couple of notes here that I'm putting down because you might think, okay, gas, sure, we'll just make a gas model and assign arbitrary values, but it's actually really important that the gas cost charge according to the actual used compute resources as in like the physical silicon how much energy and time and memory went into doing the computation. It's very important that the gas actually charge for this, otherwise you could open up attack vectors basically where you submit a computation that doesn't cost very much gas because you are clever about how you structured it, but ends up using just a ton of memory resources and that would be a way to DOS the miner for instance. Another thing is, you know, new hardware is always coming available so tuning gas cost is an ongoing challenge. It's something that you have to constantly be able to do. So for instance what happens is hard forks roll out basically hard fork just means changes to the network roll out which update the gas cost of various op codes as they find out that they were under cost or over cost or something like that. So gas is something that people kind of dismiss at first but it is a very important kind of ingredient of the whole executable blockchain paradigm. Okay, intercontract execution is another kind of sticky point with the EVM that you know, maybe could have been designed a little bit better. So you know, we want contracts to be able to call other contracts because we want library code and stuff like that, but the way that it happens in EVM allows for re-entancy because basically I can call another contract and then that contract can call back into my contract which might trigger a modification in my state and then it returns the control flow back to the contract I called and then returns the control flow back to me and I might think in my contract there was no updates to my state while I made the call into the other contract but in fact the other contract triggered an update in my own state. This is called re-entancy and there have been a lot of funds lost to re-entancy attacks basically where people have crafted clever transactions which you know trigger kind of a re-entancy cycle and just end up draining funds from contracts. The famous one is the DAO attack. Basically when you call another contract the payload that you give it is just a rostering of bytes. I'm going to call it call data here because that's what it's called in KVM but external to the EVM everyone is kind of agreed upon what's called the Ethereum ABI which is application binary interface I want to say. So the Ethereum ABI specifies calling conventions so how to interpret the call data correctly as well as some high level types and they're mapping to EVM words so it's just kind of a document specifying this is how contracts will interpret this call data when they're called with it because that isn't specified at the level of EVM itself which has pros and cons specifying it above versus in the EVM itself. So I'm going to emphasize again the nuisances versus unstructured control flow you can dynamically calculate jump destinations like nightmare for static analysis engines that want to be able to infer things about the programs based on its control flow. The second is these 256 bit words this one's kind of it's hard to know because it is useful for crypto libraries which often return things that are in units of 256 bits wide but it's really hard to map it directly to hardware for instance so it's kind of hard to decide if that's a necessary nuisance or not. What definitely is I think an unnecessary nuisance is this 8 bit word array local memory that I mentioned before so I remember in this program the first thing we had to store was at location zero and then the second thing we have to store is at location 32 and that's because when we store a 256 bit word it takes up 32 bytes worth of storage which is what this M store stores as so if we're doing symbolic reasoning and we end up hitting an M store we basically have to take this symbolic expression split it into 32 symbolic sub expressions store each of those 32 symbolic sub expressions and then you could even like shift over by some non 32 byte amount read back in and you end up with just this huge messy symbolic expression describing what your what your current state is so it can really kill symbolic reasoning this 8 bit word array thing no built in calling conventions so this this ABI is declared external to EVM like I said this is this could be good or bad it's bad because it means that basically everyone has to agree externally on what the ABI is and also it's kind of fragile so people's contracts might implement the ABI incorrectly and that could open you up to security risks but it might be good because then you kind of have some notion of upgrade ability you can say I am ABI 1.0 or ABI 1.1 so you know not really sure maybe it's maybe there's some that could be done at the level of the EVM itself instead of all of it being done externally and then basically the last one here is this eval capability so there's basically a sequence of op codes you can call an EVM which can load arbitrary data as a program and then execute it and this is once again just a nightmare for both static analysis and symbolic reasoning because basically you have to just assume anything could happen so these are kind of some nuisances with the EVM that it would be nice if we could kind of evolve away from them and all of these nuisances are directly related to security issues some of them are related to security issues like this one because it makes doing various analyses on the program difficult which you need to do formal analyses on the programs for security issues and other ones are more security issues because you could just execute arbitrary code but most of it has to do with actually enabling analyses on the bytecode level okay so now I'm going to talk about KVM what it's used for so once again KVM is the K specification of the EVM so we've specified all the gory details of EVM in K you can go to our repository which is at the beginning of the talk if you're interested in seeing the actual definition itself I figured it was probably not worth the time to explain the definition piecemeal here just this is pulled from the paper we passed the VM test and the general state tests of the official Ethereum test suite which is on GitHub and we're about an order of magnitude slower than CPP Ethereum which is a native implementation of the Ethereum client basically these numbers are kind of old so that number might have actually improved by now because there have been several performance improvements which have gotten into it but these are the numbers at the time that the paper was written so in case you're interested you can look at our paper to see more about how these numbers were collected but you know there's plenty of kind of analysis engines out there for EVM bytecode that don't even bother executing the tests but it's important to us that we have this correctness benchmark that we passed so we execute the tests we make sure that our specification is correct one thing that we have is kind of some light anti-pattern encoding stuff so EVM has this designated invalid opcode and initially it was just thrown in because they figured you know maybe we need an invalid opcode for something or another basically if it's ever encountered execution halts and all the gas is given to the miner so you don't get your gas back if invalid is hit but people have been using it in the high level languages which I abbreviate as HLL here to encode kind of assert false sort of statements so this can be in your solidity code solidity is a programming language that compiles down to EVM you can put essentially false within some conditional and that will tell the solidity compiler this should never happen and then if it does happen something has gone horribly wrong throw invalid and get the heck out because if you throw invalid it will also revert any state updates that have happened during that execution so basically we can just use K because it has a symbolic execution engine to symbolically execute the program and see it end in a state where invalid was thrown this is a pretty really simple technique and it works decently other tools have done similar things with the invalid opcode for example the solidity compiler will try to do some sort of similar analysis by taking its own kind of internal semantics of solidity building a Z3 query and then an SMT lib query and then asking Z3 does it is it feasible that I could reach this invalid opcode so this is a kind of nice technique that people are leveraging more of what you can do with K as opposed to other formalizations is you can do full program verification so I'm not going to go into super great detail here but if you are interested you can look up this paper right here Stephanie Eskut at all 2014 for how K's verification engine works and then there's also some papers on matching logic that you can look up which is kind of more recent more recent formalism for this work so runtime verification is kind of one of the companies that's largely driving the efforts behind K and they offer audits as a service basically and the typical process is first you start off specifying the high level business logic in English and oftentimes developers haven't even done this step they just kind of start hacking away at code so we'll write down a high level English description of what we think their business logic is go to them they'll say no this isn't quite right we refine it we go back to them until they say yeah it looks good and then boom they have a nice text description of what their contract is supposed to do then we take that high level business logic and refine it to an actual mathematical definition this should probably not say of logic that would be kind of a fixed stream but just a mathematical definition of their contract and then once again we go to the customer and we say you know is this correct does this look good and they say once again no there's some bugs right here and we say okay we'll go back and edit your English one and this mathematical one to kind of fix this and then eventually once we've gotten through that process we refine it to a set of K reachability claims and once again we take the reachability claims of the customer we ask them you know does this look good does it look like what you're actually trying to prove about your thing and once they confirm that indeed that is we kind of start just fixing bugs in the contract and in the specification because we could have little bugs in the specification until the K prover is satisfied and then we just send all of that to the customer basically so that's how the kind of iterative verification as a service process goes which is a lot more hands-on than some of the other tools that are being offered there but because of that it catches a lot more things so there are also independent groups using KVM to verify smart their smart contract stack EGDAP hub they you know we help them out they submit bug fixes to K and we help them out with their work when we can but slowly more people are using the K prover independently okay so the reachability logic prover takes an operational semantics as input which in our case we use a K definition to specify that operational semantics and there's no axiomatic semantics required basically it just needs the operational semantics and it kind of turns it into an axiomatic semantics the reachability logic is a generalization of horror logic so if you have a horror triple here pre-code post you can turn that directly into a reachability claim here where the code here had its variables or some subset of its variables turned into logical variables and we use the matching logic conjunction here matching logic and to limit to instances of this code which satisfy this precondition and then we say does every instance that every instance of this code that satisfy this precondition reach an instance that satisfies this post condition so I've written it out in English here any instance of code which satisfies pre- either does not terminate so we say everything is true about non-terminating paths or it reaches an instances of the empty program epsilon which satisfies the post condition so here I'm claiming it's a generalization of horror logic one way that it's generalization is that we don't need epsilon to be empty in reachability logic we can easily just make epsilon an intermediate program state and then it is a generalization of horror logic it's also not really fair to say it's a generalization of horror logic because reachability logic is a logic in its own right it has its own inference system independent of the operational semantics that you plug in orthogonal to that whereas horror logic is more of a design pattern you take some programming language and you kind of build the horror logic for that programming language so it's not really even fair to say it's a generalization as much as more kind of the right way to do it so reachability claims are fed to the K prover as just normal K rules because basically this arrow is just the same as the rewrite arrow but instead of interpreting them as axioms like the operational semantics is interpreted they're interpreted as proof goals basically and so it will use the axioms the operational semantics as well as the inference system of reachability logic which has I think seven rules to try to prove these formulas basically and then a couple things I want to mention relating to security is that functional correctness is directly specifiable as a set of reachability claims and it's kind of the adage at least I've seen a lot in like the Linux or open source community that often security bugs are just normal bugs in your program so if you specify enough functional correctness properties you can recover a lot of high level security properties basically so for smart contract verification we can because every program is terminating pretty much every property we could want we can specify as a reachability property because we don't have to even think about these non terminating instances where we just prove everything true yeah so that's that's most of what I'm going to say about reachability logic prover here is this ERC 20 case study it's in the verified smart contracts repo if you go back to the beginning of the presentation and see it there it's kind of a hello world of Ethereum smart contracts it's very simple contract basically you have in your storage mapping from addresses to values and the addresses are interpreted as you know people's accounts and the values are interpreted as how much of your token that you have so it's it's pretty versatile sort of contract you can make like these little sub economies with your own rules in them because you can just dictate how this key value store is allowed to be updated by the people who own the addresses you can just write whatever logic you want for that but there's basically a core set of methods that everyone agrees your ERC 20 has to implement including like the ability to transfer some value from one of the accounts to the other account the ability to buy some some tokens using ether stuff like this pretty much most people agree so I'm just putting some kind of uses up here you can codify ownership distribution of a company so it's like tokenizing equity this would be like you know if you think about an IPO or initial public offering you can have an ICO and initial coin offering which have caught a lot of press recently but it doesn't have to you don't have to actually do an ICO you can just use it to kind of codify you know who owns how much of a company similar sort of things with like pink slips and deeds for cars and houses you can codify a Ponzi scheme directly and you know tell people to buy into it and tell them it's a Ponzi scheme and you'll watch people buy into it but yeah so I mean I put that there as tongue in cheek just because you know of course you can codify a Ponzi scheme because it's just a logical set of rules about you know how the contract should operate basically but either way it's kind of all built on this simple ERC 20 concept so there were some problems we ran at ERC 20 was the first example we tackled with verification there were some problems we ran into regarding those nuisances of the EVM that I was talking about earlier so this is how we tackled those problems first we had to define a bunch of state abstractions directly in K itself it was nice that we could do it directly in K what was not nice was how you know long it took to develop them but now we have them and now anyone can use them so two examples of that that are particularly useful is this nth byte of abstraction and basically this lets us not actually chop up 256 bit words when we store it into memory we just kind of hold the 256 bit word itself so we don't have to chop it up into a bunch of different symbolic expressions but then if an individual byte is accessed from that 256 bit words we kind of return an expression that says you know this is the byte that you mean but otherwise we just hold it in memory so we we can kind of optimize for the very common case where you're not actually offsetting and reading an offset of the thing but then still do the correct thing in the case when you do the offset so this reduces kind of the size of the symbolic expressions that we use and then we also have this ABI call data abstraction which lets you specify instead of saying you know I want to call into this I want to do a verification verify a contract where I'm calling into it with this call data which is just a raw byte string and you know you have to kind of craft it by hand which would be really annoying instead you can use directly the function name and the signature and directly the typed arguments and it will kind of desugar that into exactly the bytes that you need to make that call properly using our knowledge of the ABI encoding and then another thing that we had to kind of lean on was we modularized how you can do specifications in K this took a while to develop but now it seems fairly robust but basically we can reuse the same specs for different implementations and this is kind of interesting because you know we then were able to go to we started out with an ERC-20 implemented in Solidity which is a high level programming language and you know spent a bunch of time verifying it and then we were like okay let's try Viper1 which is a different high level language and it generated different EVM byte code and it turns out they had different behaviors go figure because they have different compilers and they have different people writing the code so that was kind of interesting so we now have five different implementations of the ERC-20 verified all with their own different behaviors we just kind of stopped at five because we were like okay it's time to move on to other contracts that are more useful but you can kind of look at that and basically they all can reuse parts of the specification that are the same as Delta for the parts that aren't yeah so these are a lot of the kind of efforts we put in I mean there's more ongoing efforts into making using the verification engine easier but you know at the end of the day if you're doing full formal verification of your contracts it's going to be difficult and that concludes my talk as well so thanks for listening this is high level conclusion and here are some sponsors that have helped us with this project including IOHK who gave a very generous gift to both the university and the company for advancing this work