Episode 224: Foundry with Georgios Konstantopoulous

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week daruna and i catch up with our friend giorgio's constantopolis from paradigm we chat about his move to become cto of the vc firm the team he's built and what they're working on we then dive into foundry a fast portable modular testing toolkit for ethereum app

developers written in rust we look at the tooling landscape why they are making a bet on solidity the different types of testing that smart contract developers are doing the open questions about tools like this that is what happens when you introduce bridges or multiple evm chains linked together basically taruna and i just get to ask georgios all the questions we have about the project and get his thoughts about the space was really fun to catch up hope you enjoy now before we kick off i want to highlight an upcoming event from the zk validator another project that i work on so on april 15th in amsterdam the zk validator is hosting an event called privacy in cosmos this is our fourth edition in a series of events that has been funded by the cosmos hub we have a

great group of cosmos projects and privacy projects coming together for a full day of talks workshops panels so anyway i hope to see you there the event is free but spots are limited so be sure to get your spot right away we've added the link in the show notes the next week there's also a zk summit but i'm assuming that by the time this airs the spots are probably sold out to anyone who tried to apply and didn't get a spot this time around i'm really sorry about that but we will be doing more zk summits in the future we're hoping to do a zk hackathon so i hope to see you at one of our future events so now i'm going to let tanya the podcast producer share a little bit about this week's sponsor today's episode is sponsored by electric coin company the inventors of

zcash who are building the next generation of zero knowledge tech with its network upgrade 5 zcash will move to the halo zero knowledge proving system removing the trusted setup and becoming shielded by default they believe privacy is essential to delivering on the promise of a thriving and equitable web 3. with zcash and halo cryptography ecc aims to usher in an era of self-sovereignty and economic and creative freedom visit electriccoin.com to learn more and explore the relationship between privacy self-sovereignty and economic and creative freedom that's electriccoin.co so thank you again electric coin company now here is anantaroon's interview with giorgio's from paradigm [Music]

today taron and i are chatting with georgios the cto and research partner at paradigm welcome to the show georgios hello how's it going georgia's you have been a guest co-host a couple times back in the day um and this is the first time i actually get to introduce you as the cto of paradigm tyrone's also here with us today we're going to be looking at the foundry project but i think we've before we do that it would be really great to hear what you've been up to what's new in your world so what's new it's been a while since we last talked i think what's new is that recently i've been more involved in building our internal engineering efforts 2022 says paradigm from being

let's say a more research heavy like hands-on company we're also extending that to becoming software driven and data-driven for all our investment processes so we've been hiring up on all sorts of engineering roles for our portfolio and for our internal projects without diving too much into that i've recently been spending some more time on open source tooling such as foundry which i think is uh today's topic you know now now that you're you're kind of the grand puba of the engineering team you know kind of what what are kind of the high level goals you know you guys have hired a lot of famous anons on the internet so you know what what's

kind of like the the overall like theme that you think about when you're kind of building this team out too because like you know it's i mean there are a couple other examples but it's pretty rare when the venture fund builds an engineering team so what are kind of challenges and benefits of that i think there's two angles here one is on the research and one is on the internal engineering front on the research front a lot of the work that we've been doing has been in the realm of supporting portfolio companies designing new mechanisms and in particular for these skill sets we've been on the lookout for very skilled solidity engineers recently if you see we hired t11s

and frankie is lost on twitter who both of them basically were tweeting a lot about high quality solidity that they were building and it seemed like a good fit for us and to be clear i don't think unknown or not matters age not a problem either we're just interested in the best talent across the board now on the internal engineering project i think there is a lot of data in the market that is not being used properly i think that our needs are a bit more unique than what out of the box tooling may provide or out-of-the-box tooling may just not be fast enough or

cost-effective or just simply not flexible so we're gearing up to basically build that out for ourselves you've also been doing a lot of i mean at least a way that i have seen kind of the research and work you do come out is basically disclosing exploits to teams before the bug gets used for bad purposes like a lot of these yeah what do you even call these disclosures like kind of posts where you reveal oh we found a bug and we want to let people know before something bad happens i think disclosure is the right term here on our team there is something the sun who i think is probably the best hiker on ethereum and maybe other chains in the future we'll see

where basically sam is always on the lookout for other projects maybe has some automated detectors set up for identifying interesting hotspots or contracts which may get exploited and basically anytime there's some alert or every time sam is like oh there is something going on um he will contact the teams building the project ask for contacts to the teams building the project try to build the reproduction of the bug so that the teams can know what the issue is and then responsibly disclose patch if possible and save the day and this happened multiple times over

the year yeah most notably there was one hack where he saved about 350 million dollars on a sushi swap related contract and even more recently he rose to the first rank on the ethereum security leaderboard for finding critical vulnerabilities in go ethereum wow some of the people you mentioned having hired kind of an on are they truly anon to you like as a company do you have to kind of know who they are to be able to employ them you're not a dow you know perhaps perhaps perhaps okay we like to know who the people that we work with are although

we're very protective of their identities and we respect everybody's privacy to the utmost got it today what we really want to dive into is the foundry project before we do that i wanted to sort of lay the scene of like where it lives and what is similar to it like kind of what came before what tools would people be familiar with that it aims to kind of like replace or add to yeah foundry is an ethereum development tool and more specifically an evm development tool so it's not tied specifically to ethereum it can be used for polygon optimized marble room whatever other evm chain exists

it is a testing framework in the neighborhood of truffle hard hat dab tools brownie and all the other tools that have been have existed over time and its core objective is to give you a good testing environment and why is that important it is because smart contracts need to be tested properly because if they're not tested properly edge cases exist and these edge cases tend to cost people money and whenever something bad happens you see headlands with x million dollars got lost into this hack and turns out there's some missing check is it often the hacks we were just talking about that like sam actually

what how do you say his name again sam's son sam sees his son but there's also a very specific branding page on his website for people writing it okay sam suzy sun uh was sam's those those exploits that you just described are those the kinds of things that these type of tools are meant to find or they bugs at kind of a different level these are not tools that automatically detect bugs in any way these tools typically have a bit more limited scope into what they can find for you testing frameworks are there for you to get confidence that your code is supposed to do what you wrote it to do so when you write some code you write

tests and the tests say okay two plus two is expected to equal four whereas if two plus two in sum of your functions ended up be calling five clearly there is a problem so whenever a developer writes code they have this very hot feedback loop in their system which is write the code build it test it debug it right and you know you keep doing that over time and what's important is for the developer to have this feedback loop very optimized so you want both the build process and the execution of the tests to be very fast and this is where foundry kind of comes in as a tool that covers the gap from previous tooling which traditionally has

been a few times slower and we can dive dive into that in a bit yeah i mean can you share with us a couple examples of the previous tooling because i can't i mean tooling has been around there's things like truffle there's dap tools and i guess hard hat sort of goes in the same category for sure okay so right now according to the latest developer survey that was executed by the solidity team hardhat is the most popular developer tool followed closely by truffle then it's brownie and then there is you know the newer ones like foundry and the app tools so there's a core difference between the two that in hard hat brownie and truffle you write your tests

in a different language than what your actual code was so your code language is typically solidity or maybe vipered or any of the other newer languages but typically solid your viper but it turns out that in hard hat and truffle you write your tests in so in javascript or typescript and in brownie you write your tests in python and changing from one language to the other as a developer it has a lot of context switching literally in your mind like when you're writing something you're suddenly in one programming style and then you change language in a different programming style and this has caused a lot of let's say productivity laws to people and also

in the javascript library specifically there has been a lot of incompatibilities with libraries there's an infamous big number library for example for doing maths on very large numbers that people never are able to get it to work because they try to make javascript connect to solidity so dab tools and foundry they take a different approach they say you know what we want to write our tests like in every other language and we're gonna write them in the same language that we're developing our contracts on if you look at any of the big programming languages go c plus plus rust python whatever they all have the tests in the same language so here you

also write test and solidity coding solidity what are you actually running is it like a library that's testing something is it a tool is it an application yeah you sort of mention these two coding fronts so what are you doing when you're doing a test yeah originally how this worked is that somebody had to deploy a testament node this was back in the day it was called test rpc then it was replaced by another thing called ganache and what these two do is that they give you a test net node hosted locally without like any heavy database and what you do is that you literally send network requests to it saying deploy my contract then call this function on my contract then call this other function

on my contract then check that the value returned by this contract is this expected value so a test literally is something that says deploy contract call function check summa session but in the different languages paradigm what happens is that you deploy your contracts to a node and you send requests to that node whereas the difference here is that you're never deploying your contracts to a node in dab tools and foundry you're instantiating a local ethereum virtual machine and you're running calls against it in the same process and this is the core ingredient

that gives you a lot of speed boosts cool and when you talked about that node in the previous example though would that be like that's a testness testnet node i guess right yes yes a local testnet okay it was also local but in the foundry example it's an instantiation why is that different a node is composed of the evm some database and then and the set of end points that the user calls to interact with it whereas here we just never instantiate the whole rpc layer of talking to the node and just talk to the avm directly so it's okay you're you're closer to the metal in a way when you're operating in this way and by being closer to the

metal you can be more effective and more fast it's faster i guess yeah yes less layers of abstraction how do you kind of view dealing with a cross-chain world in testing right because you know as people start building more and more complicated applications across chain you'll basically need to instead have foundry run you know simulate sort of the multiple virtual machines some notion of how the bridges work and sort of like yeah what's what's kind of the way you're thinking about that are you thinking about like depth first search of like just add as many features to the existing thing until it's just like the perfect unicorn or are you thinking like breath first search of

like how do we find the minimal set of features and then expand to as many new things as possible it's a good question so basically let's say i am i'm going to test a bridge that talks to ethereum and optimism how do i test that there's a couple of approaches here one is that you think of the local chain as the place where you're testing so let's say i'm on ethereum i have the i will test just the ethereum side of things and i will mock the opposite side i will say you know instead of actually deploying the contracts on optimism i will say in my tests when some call is made to this address um insert this response as if it was executed on optimism but not

really it's never executed on optimism you just say you know play act like it was an optimism response um and this is a common pattern in testing we call it mocking it just means you know don't run the actual computation i'll tell you what to return if you receive some kind of inputs um so in this world the multi-chain testing thing is not a problem because you just always say um give me the response that you expect now if you want to properly integration test against both chains it gets a bit more complex and the reason why is because in the full node example that i said before what you do is that you have one full node another full node and you would get

state from both from both of them and run your tests against them locally however here it is a bit more complex because you have instantiated an evm with me with ethereum maintenance state and then you also need to somehow get optimism state so how are you going to interleave these two in a nice way we have some ideas around how we can do this we have not yet implemented any of this because it's a feature that nobody has asked for yet so to answer the original question i think we're going for basically get the best development experience on one chain and then we'll see if we expand and how

because right now there's a lot of games to be made on just the single the single use case it clearly has caught on you know people's you know people have started switching to it because or or sort of maybe augmenting to some extent other tools because of its speed so i guess that that sort of was was the natural question of like do you just double down on that and sounds like that's kind of your plan if you compare performance one person recently in our support channels they said that they had a brownie repository where tests were running in something like 75 seconds without any some form of advanced testing which we'll touch on in a bit um and in foundry they were running in

like 12 seconds or 13 seconds so a 5x improvement is a lot now maker dao's operations team the ones that are deploying all the governance proposals they had the test suite which when they were running it on ci on github actions it would take about 20 minutes to complete and a few i think one or two months ago when they were testing with foundry they run it in 12 seconds that's 100x faster and if you're developing this time difference it literally like is money for your business like you're paying your developers to write code so how we see foundry playing in let's say paradigm strategic positioning is that this is

the one of the most scalable forms of value add that we can add to the portfolio literally saving your developers time one interesting thing about this is like if we look at the initial foundry team it's a very multi what they're people working at multiple funds on it like you know if i if i i think about the initial team as like you brock transmissions i guess to some extent actually who would you call the genesis team and it's kind of interesting that you have multiple people multiple funds working together on building this tooling that's like pretty much pure public good right so how it started is that we had a library called ethers rs which is a toy project i had started two years ago

for mev traders to have better infrastructure which is right now used by everyone basically that does mvv trading and then one guy called matt sage had started to contribute to it he's a ras developer who was working with chainsafe and is now working with us to improve foundry and then i had started working on foundry where which at the time we were calling it daptools rs he was one of the first people to contribute to it so it started off very open source toy project let's see what we can do um almost thinking alongside of the meme let's rewrite things in rust like for fun and then it turned out that it was quite good so first it was said then i think

it was brock elmore from nascent that started to contribute who is also like one of the top contributors to the project brock is most known i think in the industry for yams i believe among other things yeah yeah there was a large large incident back in defy summer for the people that were around when you think about it that yam incident isn't even that big anymore like that would be like a blip right it is true it is true but it kind of underlines how much things changed the last almost two years like it's it's defy summer anniversary in four months wow and the and the third and i think the third person that has been like very very valuable to the project has been

oliver northberg who was one of the oldest i think he was the first hired aragon who was sort of freelancing for a time and then he started again also spending more time with us on foundry so basically the project sort of started very very organic very let's see what happens some open source contributors appeared and the ones let's say that we felt their time spent on the project would be very valuable and would be a shame if they would be spending time on something else or i would feel very sad personally if i didn't have matt oliver or brock like working on this um basically it was a nice way for us like to get them to contribute more and broke i

believe that basically all of their projects that they do at nascent um they're using foundry for development so it kind of makes sense for them to also contribute to it even though we're not involved in a more formal relationship so i would say that is the core group and then you will see a lot of a lot of people making periodic contributions too many to count i think there's about 75 or 80 people on the github repo that are actively contributing and there is about 500 like actual very technical people in the channels posting feedback posting support questions improving the project so it's not like you know it's a 500 or 1000 people chat where people are asking when talking when talking

this currently it lives within the paradigm repo though i guess right it's still within your orgs it is under my personal github right now i i'm kind of curious like does this live within the paradigm like repository or is it not is it open like how do you actually keep a project like this where does it live what are the licenses and stuff associated with it the project the github project lives under my personal github under gacon's class foundry and the license is a very permissive permissive one it's apache mit it's free for anyone to four contribute to it well i don't think we really believe in the value of the project being in kind of putting a walled garden around it and

trying to um say you know this is our property don't touch it the whole value of it comes from people coming in contributing talking about it working with it so you know contributions and forking the project are actually a metric that i think makes it look successful rather than the opposite cool how do you see sort of maintenance for a project like this going forward do you see this being something that you're going to champion for a long time do you ever imagine this kind of being i don't know taken on by another org exit to the community i think the exit to the community part you know the biggest problem with open source is

always funding so when you have an open source project you need to figure out how to have a sustainable model for it i think right now we are happy to provide and commit time and frankly like some capital to it to keep it moving forward um as long as it is good for the industry because we contribute back to the industry because we like the industry so as long as we think that this is a project that is valuable for crypto we will we will contribute to it in some capacity now whether it is me spending all my time or it or somebody else i do not know but i think we really want this to succeed right now who uses this product you know it's for testing

solidity code cool but like do you actually do you have it built like are there projects that have it like kind of built into their pipeline like what does it mean for this to be used i guess is a question i think the biggest library contract that uses it right now is probably soulmate soulmate is a project built by transmissions11 which is um quote modern opinionated and gas optimized smart contracts uh for ethereum they're basically it's a set of smart contracts that's a competitor to open zeppelin contracts and it uses foundry for testing maker dao uses it for their operations there is a and then you will see a lot

of like smaller bottom up let's say efforts from individual developers or hobby projects so basically i think that right now foundry has crossed the chasm for new developers or for you know people hacking basically it seems like they are choosing foundry but the opposite you know top down big companies still adopting it is still ongoing because primarily people have all their testing infrastructure already written in a different setup so it's harder to get them to migrate and testing is sticky no one wants to replace it because it like you you know you have the like who watches the watchman problem when you when you change your tests you have to make sure

that your new tests don't break the old test and they're backwards compatible right and like that's a lot of work that can be a lot like huge amount of work i agree so basically there's a few things we should think of tests as the glue that keeps our code from falling apart so when you're changing your tests you want your glue to be the same as it was before because otherwise your code might fall apart and you don't want that so how we've built the project is that it's very easy to run alongside whatever else you're already doing so maybe if you have a bunch of hardhead tests and you don't want to remove them but there's some areas of your code that you want to extend coverage for or maybe some of your test is very slow and

you want to make it faster you can do some kind of incremental change where you learn you run foundry alongside hard hat and you make incremental changes and there are basically example repos for every framework now there's like truffle foundry there is hard head country there is brownie foundry yeah so just to recap bottom up smaller projects i think we're in a good spot top down there is let's say some friction because of inertia but i think that projects are very open-minded and i i think we'll see a few high-profile projects in the coming months release their new versions um tested with foundry

and we use it for all of our internal projects too and the history of like ci tools in in like you know normal sort of software stuff has always had this thing where like big companies will always have like a pilot project that's like a new project that's isolated from the rest of the code base and then they'll try the new ci tool on that and then if it goes well and it's faster provides whatever benefits that it's supposed to then they like slowly expand to like the rest of their projects i don't expect that this part of the development cycle to be different there's probably like new projects within big orgs will probably start with that and then you know osmosis after that yeah i think so um you keep using the term tests but there's also like the term fuzzing are

they the same thing it's a good question so think of it like that a test says for inputs two and two the output is going to be four um whereas when you're fuzzing or testing for properties to be more specific you're saying that like calling the function add on a and b is always going to be equal to a plus b so in a way instead of testing for a specific test case because testing just for that specific test case might not touch on all edge cases instead you specify your test to be generic over your inputs and you

run the same test for thousands of inputs so instead of saying you know two plus two equals four i will say one plus one equals two one plus two equals three and you keep doing it for many many many many inputs um and the idea is that when you're writing your tests and you test them over many many many inputs you can get more um let's say confidence that your code is safe because maybe let's say for an example you have a division so a over b and you know it can be five over two or it can be five over zero and five over zero obviously does not work so you want your code to be catching this edge case okay but if you only wrote a test that

tests five over two you wouldn't be able to catch it so you need a way to be able to run your tests over as many inputs as possible to catch as many edge cases as possible does that make sense yeah i think so but i mean like foundry is you could also use that for fuzzing i assume yes yes so basically so this is property-based testing which i admit we use we call it fuzzing um but it's not you know for the formal verification people this is not exactly the right term but it's shorter to say fuzzing instead of property-based testing so apologies there um so fuzzing in foundry is supported very easily by just adding an extra parameter

to your test and instead of saying you know x equals two you run your test over x so instead of having no argument in your function you say open parenthesis x close parenthesis and your type and anytime you just run your tests your files tests also run next to your unit tests so tests without parameters are called unit tests tests with parameters we call them fastest now the reason why this is very good is because you don't need to know anything about fuzzing you just say run my tests you are the parameter and conceptually for you as a developer you just say okay my test is going to run over many inputs fantastic but before that and before how

daptools also did that which is a design that we took from there people had to install extra software to run alongside it and for developers learning to use new software installing it maintaining it putting it in the into their ci it's a pain and nobody wants to do it and so for example uh trail of bits is echidna is a great fanta amazing tool that people should be using um but it turns out that people don't bother to download it and use it because the installation process has some steps or because they need to run two software like two different commands to get their tests running this is like dependencies i guess right

this is these build dependencies it is both requiring to have you know you need to install another thing so think of it like that as a developer you want to run one command run build run test we're done you know install build test that's it whereas here you need to install build test for two things and you have a different config file for the other thing it ends up having a lot of fragmentation and especially if you start to have many repositories many projects many developers that are not used to all of this separate tooling it is a lot of overhead for you so an explicit goal of foundries to reduce the mental overhead uh that the developer needs to have for

doing their job at their at their peak performance so what we say is that instead of requiring that you install a bunch of different stuff we maybe re-implement some of the logic that other people have in different languages in our favorite programming language we bundle it all together and we give you a one-liner script to install it so you install it you build your code and you run your tests and these tests support fuzzing and they support a lot of other good things but basically the goal is to reduce friction as much as possible like for example if you if you look up how many projects use echidna right now it's not at the point where everyone like is open

to using it as much and i'd love to if it were the case but it just isn't it is still considered the power user tool is it similar i mean i know you were and i guess still are a fan of rust and like that's i remember you being kind of like very very very involved in that community when i met you are you still yes so when we were meeting uh it was uh when we were talking about i think almost a couple of years ago when i was working with cello and dalio on a bunch of the cryptography stack so foundry is also written in rust okay um and in particular it's within rock for two main reasons one being performance because rust is just very very very fast

and that's our goal here and two rust is um very portable and produces very small binaries now what this means is that i can have a process which produces a program that is a few megabytes big like five six seven megabytes which has all the functionalities of foundry for you and this is very powerful because if you if you use hard hat for example and you go to your node modules folder so this is the standard folder that every developer has when they use hard hat and you go under the hardhead directory there's like tens of megabytes of data like that need to be stored or if you have an incompatible node.js version maybe you need to to roll back to it

there's a lot of ecosystem related things that are just hidden complexity for the developer that you just don't have when you just have a tiny rust binary program that you just download you put it in your your path and just run it so the benefit here offer us this cross-platform it works on windows on linux on mac on m1 mac on arm linux and it works and it's very easy to install you can literally install it in two seconds cool actually one of the reasons i was asking the question about russ though is also like in rust there's these automated tests that are always happening and i'm just wondering if like fuzzing and these kinds of solidity tests are they at all

similar is it sort of like trying to recreate that or is it a completely different model and i'm a little off the mark i don't know i think philosophically we are designing the testing experience to look like rusts in a way like separating your contracts and your tests like in a certain way following certain patterns and so on and we indeed use a rust library for fuzzing because you know we support fuzzing in solidity but at the lower level this ends up being some ethereum byte code that gets fed to a rust fuzzer okay so your fuzzing is only as good as your fuzzer and we have identified certain

points that we don't actually like in the fuzzer and we're modifying it uh and so on so there are dependencies to your point earlier but we're trying to minimize them and especially we want to have very minimum runtime dependencies which means like you download it and you don't need to have open ssl installed for example which is a dependency that exists on many systems for example i kind of want to go back to this this idea that tyrone you had brought up about the different evms and like sort of the like cross chain but i actually wondered if as i understand it this is really built for and by the way i never know how to call this like evm for ethereum like the

actual mainnet evm but i'm saying the ethereum ethereum virtual machine i realize when i say ethereum i don't know how you call it georgios what do you call the what do you call the original they all they're all the same virtual machine they're all the same virtual machine every vm chain that exists uses the same underlying evms are they not different though are they not altered in certain cases to be fair to be fair don't don't don't forget this gnosis chain exploit yesterday showed that they're not truly uh you know one to one uh where like extra functions can suddenly get executed posts there was there is some difference for the for instance for token standards right like people have different ways of

redeploying things automatically and stuff like that oh okay sure but the actual so for people's context yesterday tuesday 15 there was an exploit on the gnosis on one of gnosis chains uh erc20 tokens because the default erc20 factory from the token bridge is not an actual erc20 it is erc20 plus an unsafe extension and this unsafe extension was abused and people lost money and and that was very bad but um it's not like the actual evm running under the hood is different okay yeah yeah yeah i i just want to make that sort of the one of the reasons

i want to bring that up is that that makes the design space for a tool like this right like an ide tool that's like multi almost you know can support all of these things it has to be somewhat aware of that at least those differences right and like keeping keeping a list of those let alone if you go to some virtual machine with like a different you know abi but you know mike the question is like when you're designing these things you're thinking about bridges how do you think about sort of these types of attack vectors and like making tests for them and making it easy for users to kind of find these types of things because i in in the cross chain world we can only expect these attacks from synthetic assets or like these like sort of implied wrapped assets to only grow

right like and i feel like testing those is like going to be like tantamount in in the future i think it's what we talked about in the beginning in the cross chain world we were either need to chain a would need to know that the contracts on chain b are deployed in a certain way so it is up to the developer i think is the kind of cop-out answer if you will um you just need to like give enough documentation the developer you know be careful this might happen i don't know that it's possible for us to warn against these kinds of things it feels candidly it almost feels a bit out of scope in a way because i can deploy my bridge and i can add

whatever code i want do you think you'll have sort of like a module system because like one thing you could imagine is that say like each layer two or or another evm chain they write their own sort of like modules that you can plug in that like automatically apply you know you have the same piece of code for the eth test and the arbitrarium test but you're when you run the arbitrary thing you run the arbitrary module which also adds in like some built-in suite that does the mapping like do you think that will be like an extension layer that people can write plugins like that because i actually think that might end up being a middle ground it's a great question you know plugins sound great until when you try to implement them

they introduce a lot of like smell i feel in your code like you need to allow for the plugin to hook into every piece of your execution and this in my experience you know most developers don't know what the hell they're doing so it's better that you just make a bunch of choices for them and say this is the tool it's opinionated use it that's it and exposing a very very very flexible plug-in system might not be the best way to do that for this specific use case i i can see it working but if that use case were popular enough i think i would prefer integrating it natively because plugins again you need

to you need to fetch them their runtime dependency and so on right but in a world where there's like five thousand evie and i mean there's probably not gonna be five thousand but but in the world where there's like hundreds of evm chains let's say right possible you i think we're open-minded to that being the case and we re-evaluate when when that ends up being the case in a way it feels like the the the scars unit here is uh time and people's kind of focus and in order to ship something that does a zero to one or a one to a hundred improvement on the state of ethereum tooling we need to be very laser focused so i think right now our core focus is we have a very fast test runner

um we run it across all repositories that we see we profile it we see what is the slowest and we try to reach something like the theoretical maximum of capacity we can get so we're going to keep improving the speed of the test we're going to keep adding more features for people to be able to explore more test cases we're going to be adding coverage we're going to be adding a formatter we're going to be making compilation parallel uh basically the idea is that want you to run like test and like in two seconds like everything is done instead of it being 20 or 30 or two minutes or whatever whereas the whole the multi-chain component in a way

right now it at least to me it feels like a distraction because it conceptually is in the realm of integration testing and not so much as unit testing it's like testing a system like a large system of like two different smart contract suites um whereas here you're specifically testing one smart contract suite and the whole crossing the boundary part feels a bit out of scope right right i i mean like i think you know when i think about products like this um you know probably the most successful version of of kind of like a development testing environment like this arguably is jetbrains and it took them a long time before they even added kind of like this type of stuff right it took

like 10 years before they added this type of stuff so i i'm just more asking you know kind of on a vision level not just kind of like a like right right to your level come on you ask other people their vision as an investor so i'm allowed to ask you a year on a vision level like where do you see the like ten years i think i think the vision level is that basically a developer installs one tool and that tool covers all their needs so if that need is indeed i need to integration test across chains we'll add it yeah i think i think that is definitely the case but basically you know i'm thinking it is kind of shocking how we're like six years into ethereum development

there's like a lot of experts that know how everything works and they have very high per optimized workflows but for let's say for the rest of us it is a bit hard for people like to do very advanced workflows without being very like multi-year experienced developers and just to say the obvious if the state of tooling and ethereum or any kind of evm chain is this way imagine how it is in non evm environments um so a lot of the features that exist here like testing against maintenance state or outputting code traces which show how every sub call the gas cost the inputs the outputs everything an interactive debugger all of these

things you will not find them in other kind of programming environments so it sort of paints a picture around how poorly developed tooling and how much how big of an opportunity there is to make things better in the tooling environment um for any kind of blockchain yeah i was gonna actually get to that like do you do you envision supporting non-uh ethereum runtimes let's say again good question i think the thing that we're that we are considering is um startnet we don't have anything built right now but the way the system works it's very cleanly abstracted it is compiler evm

test test runner so the test runner is abstract over the virtual machine or the runtime and then you need a compiler and a vm so i have identified the specific rust repository for a cairo vm which cairo is the runtime for stark net the zk roll up network built by starkware um so the idea would be we plug the kaido rust vm on foundry we plug the kairo compiler on foundry and boom foundry supports a new system now the reason why this is possible is because the semantics of startnet are very similar to ethereum there are accounts there are contracts

contracts live at a certain address you call the contracts by sending some hex data to some address and the semantics are very similar whereas if you compare that to let's say that if we want to support solana uh where the leading development framework is anchored by great developer and friend armani ferrante it is much harder and so basically i can see us i think we will support starknet like later this year or whenever we have time i can see us expanding to like other kind of languages that follow a similar account model as ethereum or startnet but kind of expanding to the solana style account model

or the the input the input accounts for each transaction model it feels like it breaks the abstraction so we cannot really touch it without building a new thing and just to fill in on what i said before paradigm is an investor in starkware and we've been longtime supporters you just mentioned uh startnet and like i was going to ask you about stuff like zk evm where they would do like solidity compiles to something else does that actually change your test are there like significant changes that need to be made to that framework so there's multiple ways to do zika vm and to be clear i'm low conviction on how this will actually work because there is

there's a whole kind of works that you're opening now on how on how complexity of generating proofs where these goes but basically the two ways to do it is either via transpilation which is what uh matter labs is doing that's like solidity that compiles down to something else right it's not the evm op codes yeah okay right so you have solidity and compiled to something that's not really vm and it requires a custom compiler and so on and there's the other approach which i think is what scroll tech is doing and actually geordi over at hermes as well they're also looking at this like yeah where it's like the op codes are actually right exactly so you you run you run exactly the same computation on ethereum

on like on a guess node and then you take the execution trace from a transaction and you make a proof out of it so basically in that way the zk part of the avm almost runs as a sidecar as a sidecar process it's nice because it's modular in a way you just have your ethereum node that does things and you just generate proofs on the side which means that this design is compatible with foundry the second one you mean like the second design okay okay so the second design seems compatible because it just uh there's no modification but i think the proving process for that is going to be very expensive okay now for the for the matter labs

transpilation or like you know different compiler approach one could say that if the compilation process is sound or like maps semantically one-to-one like from sulk and zk salk uh salk being the solid compiler um you could say you know run foundry tests against your solidity tests without compiling to the zk to the zka bytecode and if if the transpilation or if the if the different compiler maps one to one um and your tests pass in solidity then you would expect that your tests would also pass in the zta context got it uh and and i believe that's how

they're doing it like basically for doing it with hard hat i don't think that hard hat can actually like interpret the zta bytecode i know this is probably outside of the scope of foundry but like are there tests for the zk part of zk roll ups like are there is there any equivalent in right the minute you get into that other level of cryptography so for specifically for cairo in startnet for example yes there are testing frameworks where you write your tests either in python or in javascript or in cairo so we can see how like the ecosystem of ethereum has kind of speedrunned itself into reappearing over there

and yeah how it works is that they have a kind of vm it runs maybe it runs a node maybe it runs in the same process same things that we talked about in the start of the call and you write your tests and they interact with the vm and they give you an output of how they worked again this is because the semantics map one to one it's very easy like to build the new primitives based on how it was done elsewhere um on how tests work in other systems i'm less i'm a lower clarity of thought so i mean what are the other approaches like the zta vm we talked about it um the aelio approach i'm not sure how leo tests look like uh these days

yeah i i think one of the interesting thing is like things that maybe might might be like a good future episode is like to basically just get people from three different places like maybe it's like one cosmos projects like henry one alia project and georgios and we have like a like what you know what is what is this the framework because my my what from whatever little i've you know dumpster diving in the code bases i've done everyone seems to have very bespoke tests for the pure cryptography side of things especially the zk side like it seems like it's very it doesn't seem like there's like some like hey here are the like here's like the can set of tasks because like all the

all the different snark mechanisms are just so different and like you have to test very different things right like for instance if you have a really big group then like you probably have to do like fuzzing randomness testing whereas if you have really small groups maybe you can actually just like iterate through everything like there's stuff like that where like there's a lot of like weird nuance to each system that i just don't think there's like some established battery but like what what do you think there will be actually that's maybe maybe a better question like do you think like say in ten years they'll just be like the set of like default zk tests like every proving system that's implemented in code has to like pass this like schema of tests of course

they they'll get written and specialized to their particular implementation but like there's sort of like a you know in machine learning um there were always you know there's these like uh they're kind of i guess now kind of gauche or people don't even care about them anymore because they're just so integrated into the testing framework but like imagenet cfar uh stuff like that they're these like canned data sets where everyone knows what the best possible output is and like every single new time there's a new framework like you basically have to prove that you can achieve like state-of-the-art and like up to the same error and like bitwise compatibility depending depending on the architecture you're running it on

as like there's some set of tests that's true across all of sort of machine learning stuff and like some curious if you think that'll happen here i haven't thought about this too deeply so maybe the answer will be not satisfactory i think a good way to get let's say compatibility across frameworks and whatnot is to define your tests as json tests or you say these inputs should give me these outputs you put this in a file and you just say you know this is the test suite no matter what you do this is what your test framework must run so this is how for example you run ethereum consensus tests there's a big big big file consent containing a bunch of

inputs and a bunch of outputs and when people are testing out that their evm implementation is correct they literally run it across every single one of these inputs and they check was the output the expected one um independently of the language so this has been done in python and go in rust in like any language you can expect haskell javascript like every vm does that probably the most the most future-proof way yeah yeah that makes a lot of sense uh actually also you said haskell and for some reason i just realized that the zero knowledge podcast logo looks like the haskell logo it's like almost the same designer like the haskell lambda yeah it's like actually kind of crazy wow that's crazy that was my that that

was my idea i don't i'm pretty sure i never saw it but it's funny because frederick was really like the original um podcast co-host was really big into haskell so i wonder if that had any but like i came up with it that's weird it kind of does it kind of does kind of kind of you can cut this uh henrik but i'm i'm just going to send this uh yeah i'm sending i'm sending a telegram oh yeah the colors look similar you're right damn i didn't notice that until like i just like somehow you said haskell and i was like looking at the zk thing and i was like wait a minute is this a haskell look that's so funny no

i mean yeah yeah i definitely i mean i know where i my influence it was definitely not that but that is very funny yeah but i do kind of think if you make like a vision board for the zurich knowledge podcast you should like have that you should somehow somewhere merge like yeah sure i'd be down we've definitely mentioned it on the show um like all of these tests are all focused on solidity code i mean obviously it's cool like the project is around solidity but like do you think about a replacement to solidity maybe in where when you wear a different hat when you're not wearing the foundry hat are you also like you know working on that looking at new languages do you see anything ever

coming in the pipeline that might replace it contrary to popular like opinion i kind of like solidity i don't mind it doesn't matter how contrarian you know like so lid is fine honestly people like to complain about a lot of things like the language is not the problem when things go bad um people like to blame the language but it's like people just don't know how to write secure code and that happens in every language you will imagine so first of all we're working on making foundry abstract over the language used so right now it uses a package called ether's sulk we're going to generalize that to be called ethers compile so any

language can be used for that and the idea would be that you know we can use it to compile viper we can use the compile phase there's like a bunch of like experimental programming languages um and to tyrone's point this starts to look like a plug-in like system where you can plug like whatever language you want in the in the code and we can make it if we wanted we could make it look like a plugin or we could just say these are the languages now for more exotic languages we have internally brainstormed something like a solidity plus plus type thing in the past um but it's unclear what that would do beyond opinionated changes

in the syntax i think with respect to targeting evm solidly solid is quite good so the question i guess would be are you thinking about another virtual machine i think the answer is no and if you're thinking about other languages the target the avm i would say some syntactic sugar or some syntactical changes to solidity maybe but i don't know that we really need some kind of like new language or whatever it it does seem like it'd keep this by escape velocity yeah i i will say one thing we should take from like the not the like web development era on the 90s like why do we still have javascript why did we

instead build all these languages around javascript to compile to javascript exactly well it's because whoever built the first dev tooling and got the highest distribution won and like for better or worse none of the wasm stuff has totally found that fit and like it could maybe one day but it it it sometimes it's a race to build the best dev tools whoever has the best dev tools first i think that was true for javascript i agree i agree fully agree and you know people saying wasm solves this haven't tried building something to wasm so it's it's usually a hard thing to get something to work in wasm and the most advanced thing that i know that works today is cosmoism which is the smart

contracts runtime in cosmos and even them uh they're trying to make a solidity-like domain-specific language which transpiles the cosmos which ends up compiling to wasm so yeah i could see i could i could see somebody building a small like transpiler that transpiles to solidity which has like nicer syntax that they prefer but then you know you need to audit the transpiler and like all that so it's it's less than ideal something we haven't yet talked about in the foundry conversation are the sort of the two components that you've created i feel like we probably should have done

it earlier but i want to make sure i get it in so there's like forge and cast what are those two things how do they map to what you've already discussed yeah so full full disclaimer this kind of separation of like calling the project foundry and having multiple tools it comes from dab tools where dab tools basically had one tool called dap which is the equivalent forge which is the testing framework okay um and they had another tool called seth which is the equivalent of cast in foundry which is the swiss army knife and now just to zoom in so foundry is a toolbox we're not going to have just forgingcast we're going to have more tools in the

future what these tools may be we don't know it might be for matters linters it might be static analyzers it can be any kind of tool that makes the software testing process of a of a developer easier whether the tool gets integrated in one tool or as a new tool it's tbd so we just say foundry is the umbrella project and the two actual tools inside of it are forge which forge is the tool that we use for testing like truffle like hard hat like dab tools and cast you should think of it as a tool that you use when you're doing operations like you want to call a non-chain a non-chain method and see you know what was the value of this storage variable or you

want to submit a transaction so you can use it to like just do all your orchestration to submit transactions to query data from the chain and it's basically what everyone that i know uses like for debugging things that go wrong so you know you want to check do i own this token and you can write cast die balance off gacons.eth and it will literally give you back things so we're trying to make it like almost read like a natural language to some extent so that it's more user-friendly a slight slight uh step step back very high level boring question what's the etymology of all of these terms because like what's you know cause like picking a name is quite important

yeah so we we brainstormed it a lot in the foundry chat at the time um the idea that we had was it's rust so we want something that's a bit metallic and because it's tools we thought okay metal tools okay looks like a blacksmith uh style thing so where does the blacksmith live in the foundry so the foundry is the place where all the tools are and you know the forge is the thing that the blacksmith uses to forge his tools and the cast is like where all the like the hot liquid is in now why one was called forge one the other was cast it doesn't matter it was like random choice yeah we were considering doing a node

and you know there's like the idea that we might call it you know forge subcommand node so forge node or maybe we make it a standalone when we call it like blade or something like that like branding matters a lot and i i think like the whole yeah exactly each new thing has to keep promulgating the the the the message the theme so that's what exactly and if you go for example to the main documentation page which is the foundry book uh you will see that we have like a little banner which is like this guy inside his founder with like like two metal things like ford casts with liquid metals falling down like it's it's quite nice like we're branding matters a lot

it kind of it kind of echoes osmosis actually a little bit i see yeah there's the meme of the dude that's doing things yeah yeah but this is true in a lot of open source like you know home brew like the mac package manager like everything is called like casks or like brew or like a tapping a keg and and like the whole thing is built around like liquor references and it might be one of the most used packages by developers in the world right it helps right and it's very it sticks in your brain you like very easily you have these like mnemonics built in and it's like very important actually to pick these things carefully right agreed georges i think the last time you were actually on the show we talked about mev

i think we were actually interviewing the flashbots folks so what does this foundry and mev have any sort of overlap do you ever test for the impact of mev in any of these things or is it like a separate space so forge has a sub command called run which you can run against maintenant state so typically when we want to test some kind when we want to make a proof concept of something such as some citizens on breaking uh and a mainnet contract he will write a contract and he will call forge run and you will see script passed and you will be like oh we have to do something so similarly if your proof of if you're building proof

of concepts for arbitrage or for liquidations or whatnot you can use it now i have um a template repository which is called foundry rust template so the idea here being that all mev traders what they do is that they have some solidity that will talk to some rust or some python or whatever and they need to deploy the solidity they need to test the solidity and then they need to have bindings to this solidity like actual code that makes them talk to that solidity to use it in their bots so the way that template is set up it is set up in a way that you do one command run your tests or run your solidity

tests another command run your methbot tests and another command run your your actual bot with the bindings from foundry so in a way i mean this is a tool for testing so it's not like it makes you money like for map trading but it is it is built in a way that it can make your bot development experience easier okay so like the i had dean and edgar on a few months or weeks ago and they're building these boss so they could potentially use it but it's not that it's designed for that it's just their bots could be tested with it kind of exactly exactly okay exactly although in their case specifically i believe that they hook into go ethereum directly they're

customizing go ethereum so this wouldn't work out there um but yeah like there are many ways to do it like maybe they build a library that go ethereum calls to like there's a lot of ways to do this so potentially okay so a topic we probably don't have time to dig into in this episode but i did want to sort of mention quickly here is the idea of zk hardware acceleration georgios i know last time i saw you in lisbon you were talking about it is this something that you are working on is this something that you're looking at i know there's new initiatives in the space around this as well with stuff like z prize so yeah what are you doing on that i think we're very excited about the category there is many approaches to doing it and

i think i'd be glad to to bring on a guest in a future episode that can cover these topics okay you have an idea for for a guest i mean i think it's worth an episode soon for sure i mean turin you and i last year we did do we met we talked with the supernatural it's supernatural yeah yeah but they're doing they're doing all sorts of different stuff now although they are running some prover stuff right like i think they were working with elio yes they're the ones who caused that like ten thousand block fork and alia that's what the discord drama was about but but you're saying that there's another group that we should potentially talk to so cool okay so we leave that open for a

future episode for sure i think this has been a really cool kind of look into the project you were working on you've been working on giorgio's and foundry um where can people find out about it we can add links in the show notes and stuff but i don't know if you want to point people anywhere people can go to my github and it's the first pinned message or they can they pin the first pin repository or they can uh find me on twitter and it's gonna be the first tweet that they see so on twitter.comgaconst all right sounds good thanks georgios for coming back on the show once again and for sharing with us this project thank you for having me it's always great to have an uh have one of the legendary greeks of crypto back

on the show very nice and i want to say thank you to the podcast producer tanya the podcast editor henrik and to our listeners thanks for listening you