BUIDLing DeFi protocol from perspective of compiler core dev

ETHCC 5 · July 2022 · 15:05

Đorđe Mijović shares lessons from moving from Solidity compiler development to building a DeFi protocol. The speaker reviews Ethereum development tools and reflects on choices the speaker would make differently.

Speakers

Topics

From ETHCC 5, hosted by Ethereum France.

Transcript

GM everybody uh uh I will be presenting today about my way of building uh compiler and then moving to DeFi and what's the what are the pros and cons of both. Uh uh by the way my name is George. I know it's hard for everybody to pronounce it but yeah some of you may know me by my Mioich handle at GitHub. Uh so about me I will tell this in short. Uh I joined crypto uh like in few four years ago now and uh three years ago I started building stuff on Ethereum.

uh uh joined solidity core dev team uh and after that in April I started Tempus with my co-founder David and you can find me on social media and GitHub with my handles. Uh so probably a lot of you know what is solidity uh uh and uh the experience of working there is uh amazing it's completely different than anything I had before that uh the team is uh very very like uh good let's say and it's part of EF and then you are basically powering the most

deps that are out there. So, uh a lot of uh I I really suggest you to follow Twitter or GitHub and to join the conversations because they actually uh ask people to give feedback about features and uh which changed a lot in past few years. Uh and uh yeah that that's one of the biggest learnings for me as well. uh as a compiler dev, you sometimes build something that might not be even important for the use the actual users. And now what is Tempus? Uh we recently did a rebrand. It's a community

of builders, creators, and connectors. We actually build now multiple products. One of them is already deployed on mainet and it's a fixed income protocol. Uh now we are building uh like uh stark net money market. We recently announced that uh uh if you like uh want to build with us I highly suggest you check our grants and join us. There is a lot of stuff to do. Uh and what was the motivation for that move?

Uh yeah first like uh I wanted to see how to to actually use solidity and what are the pain points of it. Uh but you as a builder of solidity, you might not have the same view as uh as uh like someone who uses it. And I wanted to see how it is to use in production grade product like uh we always wrote some small solidity code but it doesn't like uh it's not even close to anything that runs on mainet. So yeah, the other is like startup vibes and being able to

build such a great team. Some of them are here. Uh yeah. So what I will go through here because we actually bother trying using most of the tools that exist. Uh I will not have time to dig deep into details of each tool. I will just go past most of them and give my opinion and what we found out on the way. Uh uh of course me and the team will follow up in uh blog post and everything explaining maybe some of these that you will see here.

Uh so language uh I was thinking that the language will lack some features when when I start building stuff but that's completely not true. There is rarely a blocker. Uh there were like annoying issues with stack 2D but that's not really huge blocker and uh for us because we use latest solidity version we have very ugly code mixing safe and unsafe math. Uh yeah uh and also custom errors they lack shorthand syntax. You can write in one line but then you are

against the code style that we try to follow. But then like uh this is something that that is just a small thing and one of the things that a lot of people and a lot of my teammates complain about is there's no full support of fixed point types. Uh there was a huge missed opportunity to do it on the compiler level. And yeah, unfortunately uh that's what it is. It will be I see there is a lot of movement to add like moldive uh op code but uh maybe it's too late because now everybody uses libraries.

Uh yeah, what could I do differently? Uh that's a good questions. I I really worked most of my time in uh solidity to you all. Uh but if I'm there, if I was there now, like if I come back, I would really do much more connecting with the people that actually write code. Uh most of the time we were getting uh uh like feedback from auditors open seline most of the time uh because they write also the the library itself that a lot of people use but still there's uh

much better communication needs to be from the compiler team to the whole ecosystem so they know how to actually participate in design decisions. I don't know how many of you know that you can join Wednesday uh it's I think at 2:00 uh central European time you can join the call and discuss design decisions. I'm not sure if anybody knows that, but yeah, that should be like something that people actually do. And uh yeah, I would probably do that because maybe if more people in the team were like for adding fixed point types, maybe it would uh be done faster. Uh but it's also when decisions are made there's a

there's a need for consensus and most of the time there's no consensus and how to do one thing there's always two ways. Yeah. So that's uh also pain point with the compiler. If you do one way half of the people will complain. Yeah. Uh development environments. So I used personally hard hit and truffle. Both of them are very good with a lot lots of features. Uh but there are uh like since we built the fixed income protocol that integrates with multiple different underlaying protocols.

uh without helpers like it was very hard to do testing uh because uh we used uh multiple different tokens plus multiple different like logics inside of the these protocols and the mathematics in each protocol are completely different. Uh so with the lack of helpers like for example starting with the simple helper for ERC20 this can be really standardized because these contracts are pretty much standard. It would be of a huge help. We ended writing all of these ourself.

Uh yeah speed of execution is good. It can be even better. Yeah I think we are better and better each year. So I think uh that's good. Debugging is very tricky. Console log and stuff like that for now. Yeah, I know Foundry uh exist. I'm excited to try it. Didn't try. So yeah, this is another good thing and they are making a lot of progress. So I'm looking forward to to to actually try it out as soon as possible.

advanced testing. Uh there are uh like uh different tools we used um like I will tell probably in the next slide but yeah fuzzers former verification like there is at least four or five of them uh uh and rarely that this is the finding rarely works with any advanced code uh and especially with plus always using the latest version of solidity which introduces some new features. Uh tooling is always very late especially for advanced testing and uh

yeah the only one for us that worked and this part of CI is Akidna uh with a few complex invariants. Yeah, we needed to write additional code but I think it was not too bad. uh mitex worked but I it worked for I don't know year and a half in CI without any major findings or any useful output like yeah that's it SMT checker we didn't use much features that would make it useful but we would definitely want to run it I worked on some features from SMT checker I would be very glad if some some of you

for example take and try to run SMT checker with our codebase. It would need to add some code but that would be very interesting to see. Uh Slitter uh we had very good connection with them. We reported multiple issues that we found. They were fixing I think we fixed five or six issues that we found like in Slitter. Uh but our code still didn't work. It was crashing because at one of the latest I think was uh that they don't support custom errors.

Yeah. Uh Sertorra approver I really have a good opinion on them but I I couldn't register account. I even tweeted them and then they sent me to the docs which don't explain anything. So I couldn't even get like uh uh trial version. Uh so yeah I can say anything for them. Uh other tools we use coverage prettier as well. Uh they are doing the work. uh test nets for us they were useless because protocols that we integrate with are outdated

uh with lio there's negative yield for example in their test net so how to use that you know for the fixed income protocol that is secondary market yeah and in general I think there's a need for better incentives for product testing right now if you run testn net maybe few community members do few actions But nobody does like bother waiting for example some time and do actual withdrawal. So uh yeah I think there is a need to have some kind of incentive for the test nets at least. Uh and this one I will just show the meme.

uh we are now building for starket and whatever like everybody complains for solidity and ethereum space this is like uh even crazier the language itself is uh very early stage uh uh and there's no tooling most of the time there's no even like code formatting tools or coverage tools uh not to talk about like uh fuzzing or anything similar to that. Uh yeah, language changes very fast and I guess that makes it fun to work in such environment and we are very excited about uh

that. Yeah. Now I wanted to tell few more words. whatever I said here, if you liked it or if you find some tool that you might uh be interested into like using in our codebase or help us improve, I really suggest that you follow us and join our discord and try to build with us and apply for these grants or even create uh your own suggestions what to build uh and how. So if I missed something here in presentation or if someone wants to actually try running Slitter or SMT checker, please come come and try. And now I will let you guys ask any

questions if there are any. Any question? All of you.