Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is Nazar Ilimanov, Solidity and Web3 dev and creator of Monobase. Monobase is a collection of tools for reading smart contracts. It includes a universal front-end for contract interactions, a scheme for creating on-chain HTML interfaces, and a forthcoming VS Code extension for writing contract interactions in Solidity. It was fun getting to chat with Nazar about his experimentation around the EVM. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Nazar, welcome to the show. Thank you for having me. I'm looking forward to talking about Monobase and all kinds of things. For people who don't know you, you had this massively viral tweet announcing Monobase earlier this year in March 2023. Was that your first taste of EVM-related fame?

Nazar Ilamanov: Yeah, and not just EVM-related. I think just first ever in any industry. So it was fun.

Nicholas: Why do you think that tweet took off? Maybe you could tell people a little bit about what the thread was.

Nazar Ilamanov: Yeah, the thread was mostly, it wasn't about Monobase itself. There was only one or two features of Monobase at the time. I think the reason why it took off is mainly due to the universal front-end feature that I created. And the features... The feature itself basically allows you to interact with a contract the same way that Etherscan allows you to. So there are a bunch of functions that you can interact with. But the thing that it does differently from Etherscan is, first, it's a bit nicer visually. And the second one is, it makes the inputs for arrays and structs much easier and handles errors much nicer. in a nicer way. On Etherscan, you're given just one input field. And how do you enter an array there? I'm not sure. Maybe it's comma-separated values. Do you have to include brackets or not? What about structs? Do you have to include the keys? Or it's very hard to... And there are no documentations about that either. I just tried to make it much easier to input. So for arrays, you get those little plus and minus buttons where you can add or remove elements from the array. For structs, you have an input field for each key. So things like that. And I think just people have been struggling with this for a long time. There wasn't a good solution. I think the only solution back then was just to have something like Web3.js or Ethers.js and just manually construct it in JavaScript. And that way you would interact. And I guess that just made things easier. And a lot of people resonated with the pain. And I think that's just the reason.

Nicholas: Yeah, because there's been a number of different kinds of takes on this. Universal front-end. But I think also the way that you described it, a procedurally generated front-end for every Ethereum contract kind of made it sound real fancy, first of all. But also the way you broke out the different data types. I don't know if I've seen any other interface that really makes that super easy to input, especially for things like structs.

Nazar Ilamanov: Yeah, at the time, I couldn't find it either. Right now, I saw a few other things that do similar stuff. But yeah, you're right. I think also the way I positioned it, I guess I made it sound something bigger than it was. It was just like a simple thing to interact with the contract. But if you think about it, it's really just like a procedurally generated front-end for any contract. Yeah, the front-end consists of just the forms and inputs, buttons, but it's still like a front-end nevertheless.

Nicholas: Yeah, absolutely. And I mean, everybody's had the experience of minting something or claiming something via ETH. Etherscan and kind of having that trusted, as you say, procedurally generated interface. But I'm curious, have people enjoyed Monobase beyond the original pump? Are people still using it to interact with contracts?

Nazar Ilamanov: Yeah, definitely not in the same volume as it was initially. But every now and then, I see some tweets mentioning that they really like it, that it's much better than Etherscan. It's definitely not at the same volume, but I also added a few more features to Monobase. They weren't quite as useful and popular as this universal front-end. But yeah, people still use it. for, I think the main use case for now is just the edge cases. when Etherscan isn't enough or other tools isn't enough, they go to Monobase. I think that's the main use case for now.

Nicholas: Well, we'll get into it in a minute with the other features you've been coming up with and other sort of aspects of the product you've been using. And exploring in almost a year now since you launched, I guess nine months, something like that. Yeah. But I'm curious, have you ever done any other types of dev before working in the EVM?

Nazar Ilamanov: Yeah, my background is traditional Web2 engineering. At college, I had an Android phone and just at the time I had a computer vision and computer graphics class. So I just decided to build. an Android app that extracts depth maps from a real-time camera, just given RGB images, so real-time camera feed, you take that and try to build depth maps out of that feed. I just created like a simple app and there was a career fair at my college and I just tried to get an internship and I didn't have anything to showcase except this app. So I started just showing this app, here's what I can do. And one company liked it and they hired me as as an intern for their Android development. So I did some Android development there. Then when I graduated from college, the only experience was this internship, the professional experience. So when I started applying to jobs, I also just ended up applying to Android developer positions and I got a job as an Android developer. So that's how I got into Android development. But I've been doing a lot of. Web development on the side, all my side projects include some kind of web development, either React, like Next.js, things like that, and like about three, three and a half years ago, I got sucked into the Web3 space, you know, was fascinated by the paradigm. It's very different from Web2 and like, you know, in Web2 you deploy these little programs that run on a shared. Server in a way, and there's no third party controlling the execution. You can just anyone can just interact with it. So it just blew my mind. And ever since then, I started exploring Web3. Awesome.

Nicholas: So Monobase talks about sort of advertises this letting you browse the Ethereum monorepo and thinking about Ethereum as a monorepo. What does it mean to treat Ethereum smart contracts like a monorepo?

Nazar Ilamanov: I think. Like, if you think about it, Ethereum is just one big execution environment for all the contracts deployed there. And it's not like if you compare it to Web2 model where like GitHub, it has a bunch of repos, they don't share any context at all. Like they all run in different environments. And unless there's a specific API that a certain application provides, you can't really interact with it. You can't talk to it. So it's kind of like a bunch of silos. A bunch of applications that are disconnected, but on Ethereum, every contract just gets an API out of the box. You don't have to implement it yourself. Like if you write your contract in Solidity, if you expose your functions as public, you don't have to do any additional work. Those functions will just be like anyone can call them. So when you compare the Web3 and Web2 model in Web3, everything's in a shared context and it just. It's really similar to the monorepo approach of Web2. In Web2, there's a way to do that. You just have like one big project and within that project there are separate applications, but they all can talk to each other. They all share the same code. In Web3, you get that out of the box. And I just with Monobase, I'm trying to build an explorer that takes advantage of this feature of Web3. So, for example, when you browse some contract and there's a link, there's an address. Reference there in the source code, let's say like some contract implements some functionality on top of some ERC20 and there's an address of that ERC20. We can highlight that ERC20 address and allow the user to go to that address. Like we can link that address and the user can just navigate seamlessly between contracts without even realizing that, you know, there are separate repos to the user. It's just the same, the same monorepo. You're just browsing different, almost like files.

Nicholas: Yeah, definitely. I've also seen I'm blanking on the name right now, but there is what is the Ethereum contract sanctuary, smart contract sanctuary, I think it's called. Yeah, yeah. Which also kind of sort of manifests this notion in a different way in a GitHub repo that is pulling down all the verified contracts, as far as I understand what it's what its functionality is, but also sort of puts them all into one big repo in a different interface inside the GitHub interface. Right.

Nazar Ilamanov: Yeah. The sanctuary. I think if I understand correctly, the initial reason was to just store the source code of contracts in a place that's not Etherscan, just download everything from Etherscan and make it available to public. But yeah, if you think about it that way, I think it's also kind of like a monorepo. All the contracts are in just one one repo, but it's just missing like Web3 specific features. That could improve the user experience. like you can't just if you see an address, you can't just click it and be taken to that contract. Yeah. So it's kind of like almost like a Web2. take on that. And I'm trying to do like more Web3 trying to integrate Web3 specific stuff into my Explorer and not just like linking. Also, the good thing is that the good thing about Web3 is. You can just call a function and you get the results like let's say there's a function called get some X address and that address returns and returns the address and. You can essentially integrate the results into the source code itself. So on GitHub, the source code is just static. You don't know what the values are. You don't know what if there's some value stored in database, you don't know what that is. But in Web3, you can. you can integrate the line. Live values into the code itself. So I like what the contract reader is doing. They are integrating the results, the live results into the code itself. So I really like that idea of integrating the results into the source code so that the source code is not static anymore. It's filled with live data. And that also allows you to navigate this more repo easier.

Nicholas: Right. It's not just the source code like in the contract sanctuary, but it's really interactable and connected to the live blockchain.

Nazar Ilamanov: Right.

Nicholas: At its core, Monobase generates a front end for every Ethereum contract. Maybe you could take me through the steps. Like, how do you actually do this? If someone wanted to recreate Monobase or just understand the process that you went through to collect all the information, what are the kind of steps for actually doing that? Maybe for the moment, we can just stick to one chain. Just let's just say Ethereum L1.

Nazar Ilamanov: Conceptually, it's very simple. You just have to find an ABI of the contract. And right now I rely on Etherscan for that. So I query Etherscan. The source code. Yeah, you don't actually need the source code, just the ABI. And I think this one, like one thing that we need to fix with Etherscan, there's essentially nowhere else. There are solutions like Sourceify, but in my experience, people don't use them for some reason. I guess it's just a little bit more complicated than just verifying it on Etherscan.

Nicholas: When you say people don't use it, you mean that people, when they're deploying and verifying contracts, are only verifying on Etherscan's private centralized service? Yes. And not sending it to Sourceify, which is more like an open source repository of verified contracts, right?

Nazar Ilamanov: Yes, yes. Yeah, I think Sourceify simplifies this process a lot. Like you can do it yourself by deploying to IPFS, because I think at the end of the day, what Sourceify does is it just uploads the source code to IPFS. Oh, okay. Yeah. So I don't know why people don't do that, but just from my understanding, I looked at the Sourceify website. And the number of contracts that were verified with them was much smaller than what Etherscan has.

Nicholas: Maybe we need to lobby Hardhat and Forge to change up the defaults to doubly verify. I feel like maybe Forge does send it to Sourceify also.

Nazar Ilamanov: I think so, yeah. I saw some kind of flags, I think, if I remember correctly. But I think on IPFS, you need to pin those things, and that just complicates things. Etherscan, you just upload them, and Etherscan takes care of hosting. But on IPFS... But essentially, Sourceify covers the cost of the pinning for people. I think so, yeah. Yeah.

Nicholas: I think that's right. But I'm not 100% sure if you get someone on from Sourceify. It is interesting that we all rely on Etherscan for this. It's kind of a point of centralization. If you don't have the ABIs, then you don't know how to interact with the contracts, right?

Nazar Ilamanov: Yeah, yeah. And to get back to your initial question of how you can generate a procedure to generate the frontend. So you get an ABI. And that ABI will have pretty much everything that you need to build this frontend. So it will have all the functions, all the arguments to the functions, the return values of the functions. It's just a matter of transforming those values into a readable way. For structs, for example, the ABI itself is very kind of... All the information is there, but it's not the best representation to build a frontend. So you have to do some kind of... Transformation of that data to make it easier to build the frontends. So you have to extract the struct name. And whenever that struct is referenced in arguments, you replace that argument with the struct name itself. So things like that. So you do some transformations. And from that data that you get, you just build a simple frontend. And the frontend itself consists of just a form, a bunch of inputs for every type of... Value. So for integers, it's going to be one field. And maybe you say, like, type number. For strings, it's type string. For address, it's type address. And if you want to do some kind of fancy stuff, if you want to validate the addresses, you add validation on top of there. Also, maybe if the user enters a random string into an address field, you highlight it and say, this is not an address. This is not a valid address. Things like that. And once you have this frontend... I think you should be pretty much all set. Except there's also the wallet connection stuff that you need to implement. But I think there are a lot of good libraries. Like, I use RainbowKit. And they just provide this easy-to-use pop-ups for connecting to a wallet. So you just integrate that and just host the resulting thing somewhere. And that's pretty much it.

Nicholas: You're also doing some clever stuff around figuring out the units that are returned from read functions, for example.

Nazar Ilamanov: Oh, yes, yes. That's another thing. Like, if you want to get fancy, you can... For example, integers can represent all kinds of things. It can be just a number. It can be a timestamp. It can be an ether amount in a way. So if you want to get fancy, you can look at the value. If it's higher than a very big number, it's likely representing amount of way that was sent. If it's somewhere... Somewhere in between. Like, if it's a little bit smaller, it's probably like a timestamp or a block number, things like that. If it's a very small number, like five or six, maybe just leave it as is. Don't do any transformations because it's probably representing some kind of count or something. So I did implement that component. I think it gets things mostly right. But I've seen a few edge cases where it breaks. And it's just, I think, impossible to cover all cases. But I have this fallback. If you don't like them... Inferred value, you can just see the raw integer value.

Nicholas: Right, right. Speaking of edge cases, what kind of edge cases make it hard to make a universal frontend? I guess there's contracts that don't have ABIs. on Etherscan, perhaps?

Nazar Ilamanov: Yeah, that's definitely one edge case. For that, I use a library called Watsabi, I think. If I pronounce it correctly, Watsabi. And it's created by a guy. His username is Shazo on Twitter. It's a very good library. Given a bytecode, it tries to infer the ABI by looking at the function selectors. So in Solidity, when Solidity compiles stuff into bytecode, there's a function dispatch, a thing called function dispatch, where it tries to match the initial four bytes into the four bytes that are stored in the contract itself. And from that... From that dispatch, I think it's possible to infer what kind of functions the contract has. So that library takes care of that, and I just try to implement a frontend out of those inferred functions. It fails more frequently than the correct ABI, but I think it's still better than nothing. I provide a way to write your own ABI. So if a contract is unverified, but you are certain that it has a certain type... You can just manually write it in Solidity, and I do the compilation in the backend and extract the ABI from that. What other edge cases?

Nicholas: Just for what's ABI for one second. So it's not just doing a lookup in the fourbyte.directory. It's doing something else.

Nazar Ilamanov: Yeah. So in order to look up from fourbyte ABI directory, you need to know the four bytes of... Basically, all the four bytes that are used in the contract. So that library is... It doesn't do the lookup itself. You have to do it manually. What it does is it kind of decompiles your bytecode. Given bytecode, it extracts all the four bytes that are present in that bytecode.

Nicholas: And then you look them up.

Nazar Ilamanov: Yeah, yeah, yeah. I see, I see.

Nicholas: And then the fourbyte directory is just like a list of all the four bytes function selectors that have been verified previously.

Nazar Ilamanov: Yeah, it's a database that have either been verified previously or scraped. I think... I think Samson, he has a very good database. I think he doesn't say how he scraped the web, basically, for these things, but he has some clever ways of doing that. Maybe like you can scan all the GitHub repos, compile all the contracts and extract all the four bytes. That would be a very naive way and probably very expensive. But that's one way, I guess, just look at previous transactions and try to infer... All the four bytes that were previously sent, that's another way. There are, I'm sure, a lot of clever ways to do that. But just like, yeah, in the end, you build a database of four bytes. And that database maps from some four bytes to a human readable string. And that human readable string is representation of the function with its arguments.

Nicholas: It reminds me a little bit of that time somebody sort of brute forced the inverse bra function. With a bunch of different parameters to match the four bytes for a contract deployment. And then one day MetaMask was showing. every time you went to deploy a contract via MetaMask, the contract deploy was replaced with this inverse bra function name. I assume that they were doing something similar, but sort of just sort of iteratively packing it with different kinds of arguments in order to try and get a collision in the four bytes with the contract deploy four bytes.

Nazar Ilamanov: Yeah, I remember that when it happened. At the time, I wasn't... I wasn't very familiar with EVM at that level, but it really fascinated me how such a thing is possible. And I just started learning about how this works. And yeah, I think like what happened there is MetaMask used some kind of public database to look up the four bytes. And that inverse bra guy, he manually just took a string. That starts with inverse bra and I think there were some kind of random characters appended to that and he would just manually brute forcing all those strings and trying to get the same four byte selected. Same as I think all the contract deployments, if I remember correctly. So whenever there was a contract deployment, the initial four bytes would match the selector that you would get by hashing inverse bra. And... Yeah, I think it's not too hard to find a match. It's probably like not a very hard cryptographic problem. So it's all clever, though. Yeah, it was very clever. But I think MetaMask knows how to handle such cases now, so I don't think it's possible today. Yeah, yeah.

Nicholas: Were there any other edge cases that come to mind that make it difficult for building a universal front end? I guess ABIs is like this kind of big looming one that the ecosystem has sort of yet to be able to handle. To figure out how to get a better ABI database than Etherscan. But it maybe is more of a social problem around verification than anything else. Yeah.

Nazar Ilamanov: I think, like I said, the front end that I have right now is very simplistic. It's just like given all the functions, you get a way to interact with every single function. But I think it's just not ideal. Sometimes you want to do, for example, multi-call. You want to interact with two functions in a row. And maybe the second function depends on the result of the first function. And what do you do in that case? It just gets very hard. So those edge cases where you need more than just a function interaction, I think those cases are still not handled well with the stuff that I built. And I was trying to experiment with a lot of things. How do we make it easier? One thing I built was, I initially called it Universal Query. Basically, it allows you to write arbitrary solidity. And I would show you the result of calling that solidity code. So you can write arbitrarily complex queries. You can implement multi-call there. You can do all kinds of transformations of the values returned from functions and then present that to the user. It wasn't as popular as this, Universal Frontend. So I guess people don't have that pain, but to me, every now and then, it's useful.

Nicholas: I've heard you're also working on a VS Code extension related to MonoBase. What's that about?

Nazar Ilamanov: Yeah, this VS Code actually was, I started working on it after I was frustrated with the editing experience, editing solidity in a browser. Yeah. Yeah. I tried to implement it manually on MonoBase for Universal Query that I just mentioned. So Universal Query, just to give more context, it's just like a big text area input field in a web page and you write your solidity there and it highlights the syntax. So it's not just like writing plain text. So that part is good. But then, like, you need to handle all kinds of edge cases that IDEs already provide. Like autocomplete. That's very hard to implement, linting, highlighting, like errors, things like that. And I didn't want to implement all of that from scratch. And I thought, why are, why am I requiring the user to write something in a web page when there's a much better place to write the code, which is the ID, the VS Code ID? So that's how I decided to build an extension. And I want to pack things from MonoBase. From MonoBase into this extension that requires some code editing. So Universal Query is one example. So the way I packaged it into the VS Code extension is I created a Jupyter Notebook like interface. If you're familiar with Jupyter Notebook, it's like a bunch of cells and you write your code, hit enter, it shows you the result of that code and then you can write more cells on top of that. Which can, like the status persisted across the cells.

Nicholas: Like a linear notebook REPL.

Nazar Ilamanov: Yeah, yeah, exactly. And I saw that idea. Samsung was building it last year, I think at the end of last year. And I was fascinated by, you know, just being able to write solidity in a notebook environment. I think it's very useful for creating proof of concepts, POCs, because if you look at Code Arena, a lot of people write code. POCs, but they're all either like just text based or it involves Foundry tests. So in order to run them, you have to clone the repo to your local machine, install Foundry. If you don't have it, then run tests, make sure that the results match what they're what the expected value is. So it's kind of like a little bit less than ideal, I think if there was a way to just see the results as you write them, just hit one button. And you see the results. And that would be much nicer. And this idea from Samsung of creating a notebook really, I think, resonated with me. And I think he ended up not launching it. He, I think, abandoned the project, but I decided to build something like that. And so far it works for simple cases. And I really like it. I'm working with Backseats, who is the creator of Contract Reader on the project. And I'm using it. I'm using this POC, the notebook thing, and I'm using it to share in-progress stuff that we have. So I implement something, I show it to him, like, here's how it works, like, here's the proof that it actually works because you can see the live results that this is outputting. And it's a good way to share stuff like because otherwise what would have to happen is I would have to create a repo. He would have to download that repo, run the tests locally, see the results. Okay. Verify that everything. But I think this is much nicer. You just share the notebook, he can see it in a web page, he can see the results, and he can integrate it into his own ID.

Nicholas: The Universal Query Interface, when I go to it on a given contract, it's like a contract that makes a call to the contract whose page I'm on. Can you explain a little bit, I guess I didn't quite understand what the idea is for this, just to be able to in solidity write a contract call? Yeah.

Nazar Ilamanov: I think that's the reason why I don't get that much usage for this. It's because it's very complex, more complex than it needs to be. And yeah, my initial motivation for building it was to be able to write arbitrary solidity and read the results. that way instead of like, let's imagine, how would you query, how would you resolve an ENS name? How would you get the address that belongs to it? Right. So you have to interact with the ENS registry, you have to get a resolver contract for that name. Like, let's say, Vitalik.eth. Right. So you, like this string, Vitalik.eth, you clear the ENS registry and say, what's the resolver for this string? It gives you a contract. Then on that contract, you actually say, okay, resolve this Vitalik.eth string. And then it gives you the... Okay. The address. And there are some steps in between, like you have to hash the string because like solidity doesn't understand strings. Well, at least the ENS implementation doesn't understand. So you need to provide hashed bytecode, hashed hex code. So basically there's just a lot of steps. And if you were to do that with the universal front end that I built, it's just involves a lot of complicated interactions with different contracts. Okay. And I decided to build a way that allows you to write all that solidity in a given function. And I would do the compilation process in the back end, turn it into a valid query, like simulate the deployment of that code that you wrote and simulate the execution of calling that code and give you the results. Basically, just like a bunch of simulations. And in the end, you get the results that you wrote as if you just executed it. I'm not sure if that makes sense.

Nicholas: Yeah, right. It's kind of a solidity first way of interacting with live contracts.

Nazar Ilamanov: Yeah. It essentially just accomplishes the same thing that the solidity notebooks and the extension are doing, but just in a much weirder way than it needs to be. I think a better user experience is to write the same thing in the solidity notebooks. And I'm planning to actually close that. Because it just requires a lot of maintenance and notebooks are a much better interface for this.

Nicholas: Great. And notebooks will come out as that VS Code extension.

Nazar Ilamanov: Yeah. It's already live. Oh, okay. Extension is in the marketplace. You can download it. Yeah.

Nicholas: Solidity notebooks, it's called.

Nazar Ilamanov: It's called Monobase.

Nicholas: Oh, it's called Monobase. Okay. Yeah.

Nazar Ilamanov: There are solidity notebooks. I'm planning to add more stuff into there. But for now, it's mostly just solidity notebooks. And you get the universal front end. Yeah. Within the extension itself. So I noticed a lot of people were deploying their contracts through a test net and then seeing how it would show in the universal front end. So it's just a bunch of steps you have to deploy and then see how it looks. What if there was a way to just, you know, you write a contract in IDE and you already see the universal front end alongside. So I also added a way to do that. So for all your contracts that you're developing locally, you can just. Open a tab and see what the universal front end would look like.

Nicholas: Right. Makes sense. Makes sense to have that right inside of VS Code too. Yeah. You've also been exploring on-chain generated HTML interfaces. What's the big idea here?

Nazar Ilamanov: I think the big idea is first decentralized front end. I think a lot of people also resonate with that. They want the front ends to be decentralized, especially after recent, like, you know, SEC stuff. SEC stuff with the mixers and Uniswap blocking certain actions. But another use case that I want to cover with this is being able to remix other people's front ends. Like, let's say you have a front end for Uniswap. You don't like one small thing about it. What would you have to do today? You would have to. If the repo is open, you clone it. Try to find a place where you need to modify the code and deploy it somewhere. What if it was just. What if everything was on-chain? You would just remix a single component. Deploy a new contract for your updated front end and everything would just be served the same way like the initial front end. If that makes sense.

Nicholas: So censorship resistant and potentially remixable interfaces. Served from the blockchain in order to interact with smart contracts.

Nazar Ilamanov: Right, right. That's a good way to summarize it.

Nicholas: Okay, good. So I'm curious how. I know we talked about this a while ago when you were first working on the project. But I'm curious if you can explain a little bit about how you approach this problem. Because it's not so obvious how you would sort of efficiently store HTML interfaces on the blockchain that could be served via view functions. So how did you go about it?

Nazar Ilamanov: My approach. Which is probably not the best way. I'm still experimenting. But my approach is. There's one function called get UI that a contract needs to implement. And that get UI just returns a string. And block explorers like Etherscan or Monobase or other explorers would be able to look at the contract. Check. Does it implement a function called get UI? If it does. Then we consider this to be a front end component. So we take the string that's returned from get UI and insert it into an iframe. And just serve it as if it was a website. As if you got that HTML from a traditional web to like Vercel or something. And the contracts themselves are free to implement this. get UI. However they want. They can write the components in Solidity. So they can do a lot of string concatenations and construct the front end out of just those composed strings. That was my initial approach. And I spent a lot of time doing that. I even built a syntax highlighter similar to JSX but for Solidity. Like in JSX you can write JavaScript. I mean you can write HTML within JavaScript. And I wanted to have something similar for Solidity where you just write HTML within the Solidity itself. And it would just do all the concatenation, all the stuff in the back end. But I just realized it's not ideal. And I think that was our conversation from last time. I think you also disagreed if I remember correctly that it's not the best way to do it. Like writing HTML in Solidity is not ideal. And initially I was against it. But now I think I agree. First because it's too hard. There is no tooling. Second is you lose a lot of work that's already been done. So there are a lot of great libraries that have been created already for React, Svelte, whatever you want. So there's a lot of work that's been done already on the front end components. And if you require everything to be written in Solidity, you have to do everything from scratch. So I kind of abandoned that idea of writing components in Solidity. And instead I think I'm more leaning towards building your components using whatever framework you want. Like React, Svelte, plain HTML, whatever you want. You compile that front end. Not compile, like bundle. Because in JavaScript there is no compilation. You bundle it into one HTML file that would have the styles, the JavaScript, the HTML structure. Everything in just one file. You take that file and store it as a string in a Solidity contract. And when the users call get UI, that function just returns. It spits out that long string.

Nicholas: So you just package everything up into this string version and then the string just shows everything. So there's no sort of in-memory. In-EVM computation of what the interface should look like. Instead it's just sort of created and built and stringified off-chain. And then stored in the contract. Maybe permanently or maybe in a mutable way. But it's not generated on-chain.

Nazar Ilamanov: Yeah, exactly. You're not constrained to doing that. You can maybe get two different strings for two different components. And do just the concatenation of those two strings in EVM. And maybe you can add some EVM specific data. For example, you can create the balance and insert the string of that balance into the HTML. Into the right place. So that the resulting HTML has that string as if it was created from blockchain. So today how you would do it. You would have a library like VM or Ethers. You would need an RPC provider like Alchemy. And you would create the balance and insert it into the HTML using JavaScript. But if you do it the Solidity way. Then it's possible to query the balance as part of that function call. Turn the balance into a string. And just plug it in into the right place into the HTML. And the resulting HTML would already have that balance as part of the initial state. You don't need an additional RPC call. You don't need libraries like VM or Ethers.

Nicholas: Yeah, that reminds me a little bit about how I did the Juicebox metadata contracts. Including if people are curious. You can see them on juicebox.cards. Where essentially every Juicebox project has its own NFT. That represents ownership of that Juicebox project. And I created a metadata registry. That would by default give you metadata for each project. Representing the current balance of that project. And other sort of live variables that are concatenated into the onchain SVG. At the time the view method is called. To generate the token URI. You could do something similar. But instead of generating SVG. You could of course do HTML. And you could do things like. As you're saying for token balance or something like that. If you want to have an NFT that shows. I don't know what the total supply is. Or what its own token ID is. Or you could do things like. I think even maybe in one of the examples I saw from you. You can go and grab the contracts address. And my dream has always been to. Maybe it's been done. But to serve the HTML. From which you can do contract interactions. From the contract itself. So an NFT contract for example. Could serve its own mint page directly from the chain. The problem then becomes. To what entry point do you go. In order to make the initial RPC view. Function call. To get this UI. From the thing. Because there's no. There's no website that does that yet. Or there's no. And obviously. You know. Traditional web browsers don't allow you to interface directly. With the ETH node RPC network. So you need to find some entry point. That would allow you to bridge the gap between. Most likely a regular. Web browser. If you want to be compatible with lots of stuff. And making that RPC. The initial RPC call to populate the. The HTML. From which you can do the rest of the interactions. Of course. Such a thing. You can even do things like that. And serve HTML directly to. For example. The metadata of an NFT. But. That metadata is sanitized. If you're looking at it through something like OpenSea. For good reason. Because you could be injecting all kinds of weird JavaScript. Into. The. OpenSea. Page. And so you're not able to like. Mint an NFT. From within. An open. NFT on OpenSea. Because. As far as I know. At least. When I last checked. They. Sanitize the. Metadata. When it's painted. To the cached version. Is painted to the OpenSea interface. Because they don't want you to be able to. Spawn. Transaction requests. To the window. Ethereum. Metamask. Or what have you. For good reason. But I think it would be great. If. I mean. You can imagine. In the era of. Cheap L2s. For example. How cool it would be. To just be storing. Simple HTML. Pages that. Embed. Their own. RPC. Calls. Like for example. Mint buttons. For NFTs. Or. Interactions with other kinds of. ERC20s. Or you can. You can imagine. And they're all served directly from. Some L2. Rather than from. AWS. Or Vercel. Or what have you.

Nazar Ilamanov: Yeah. I totally. Agree. Yeah. Absolutely. On some kind of. Website. That. Does the initial query. Initial view. Function call. Uh. I think. Even. If you start. With that approach. It's. Already better. Than. Nothing. Maybe. There. Are like. Interchangeable websites. Like. If you don't like one. You can switch to another. But these websites. Maybe. Let's call them wrappers. queries the wallet connections. maybe we'll even provide rpc uh url if you need to uh and maybe if we if we are successful in like creating almost like a web standard for clearing the contracts then i think that's a step forward.

Nicholas: yeah absolutely i i've always thought of this um and i think this is what we talked about when you first presented me to your idea. um i've always thought about this as like uh. i guess primarily from the nft perspective is why i thought of it this way but like an nft browser or maybe more broadly just a blockchain browser where it's a website that really is just making that initial connection with a free rpc node unless you have uh an injected wallet that has its own rpc in it. so you can just check if there's if there's a winded out ethereum uh you know wallet injected into your browser. if not then use some free rpc node from cloudflare or whoever is offering the freest one the highest rate limit. make the initial request to um some contract that uh let's say we put out there on i don't know uh optimism or some some l2 and then um maybe from that page uh be able to find discover other pages that are out there uh that are hosted on on the blockchain. and then you do as you say you have this kind of single dependency on some centralized uh and it could still be served from ipfs and whatnot. but there's going to be some um regular url that can be accessed from a regular browser and then uh that just makes that initial connection but that that code could be open source and and serve from a number of different addresses. so it's not a problem. i guess the question would be some details around what the expectation what that browser expects this uh you know something like a get ui interface uh to serve. i'm not sure what the right answer is around that.

Nazar Ilamanov: yeah i don't have a good answer either. it's just still an exploration. so i'm just like trying to play like this you know trying to create interesting experiments and see where it goes. if it becomes something then it's good. if it's not then we'll just move on to the next experiment. i consider monobase to be like a playground for me to create all these kind of interesting experiments that i think are missing today from. uh ecosystem.

Nicholas: yeah it's it is interesting to me this i mean uh your get ui interface could be good. i know there's also and i i think eventually hopefully it'll be on the show. but uh ps horn and his fourth energy uh project is kind of related but also gigabrain in some way that i'm not sure very many people understand yet me included uh but that project attempts to do something similar but also has a concept of fetching resources from across the world across the multi-chain verse. so instead of just requiring the resources live on the same chain. uh you could imagine pulling you know an html from base that then goes and fetches a font on optimism and uh uh i don't know uh some component on arbitrum etc. um i'm not sure how far along that is but i think he has some very serious ideas about this. hopefully get him on the show eventually. but i think that even just a basic version i mean i guess immediately you run into the problem. we um not only uh abi sort of solid abi database outside of etherscan but especially one that's available within the scope of of a blockchain execution. there's no way that if you call a get ui function you can reliably know the abis and you can't compute them either because that what's abi library is not something that's going to be executable on chain. so there's no way to create a universal front end for contracts that is served from the blockchain because you don't have access. yeah but if you have front ends on chain then maybe you don't even need a universal front end.

Nazar Ilamanov: every contract would just like you know uh be able to create front ends.

Nicholas: well it should but you'd have to. contracts would have to write their own abis to the chain i i think because they don't right now. yeah that's true. i think an abi registry that's on chain would be very cool and there might might even be experiments that have already gone in that direction. but i guess just in general people don't want to pay the gas. and from the perspective of someone deploying a contract who doesn't particularly care that it be sort of coherent coherently available through a website served from the chain then they're never going to deploy the abi.

Nazar Ilamanov: so uh yeah it's the guess. and also just like a verification how do you make sure that the abi that they sent it's actually the correct abi? for that to all do everything on chain you would i think need the entire compiler to be on chain because i think that's the only way to get the correct abi.

Nicholas: am i crazy or has that? has someone done something like that?

Nazar Ilamanov: i haven't heard about that. i think it's. uh. you could do something like maybe with the zk stuff because that would be well first very uh expensive in terms of gas to put the solidity compiler. if you want to compile something on chain that's i'm sure pretty gas extensive. and the other thing is how do you turn the compiler into solidity? because you know uh right the soul c is written i think in c plus plus and it's just very hard. you could do it with zk but i think today's zk is not at a state where it allows you to model this complex operation as a as something verifiable using the zk technology.

Nicholas: it's very interesting. i think it would be cool just even as a start to do some simple contracts that are only self-aware and able to serve their own uis uh directly from the chain. i think it's just. it's just a simple enough thing to do. uh that it would be worth doing it. you should be able to mint an nft from a website that is essentially served from the chain and then as browsers like um if you're i think if you install metamask for example into your browser then if you type in a dot eth address in the address bar omni bar it will go and fetch the text record corresponding to that ens address and then just take you to the page directly if you have metamask. uh at least in i believe so it is possible that you could even have skipped the websites and just have um that sort of rpc browser piece wrapper as you described. it served uh via ipfs and in the text records of an ens and then you wouldn't even need a url as long as the people as long as people accessing it have. metamask. yeah maybe we should do a little proof of concept.

Nazar Ilamanov: that'd be very cool. but i think in order to get something like that into like the web standards i think we need much more usage than we have today and it's very hard to push something like that at the current state of things and to actually get users. we need to build fun stuff. so for now just i think the best way is to keep experimenting. uh and if there's something very useful to be built i think those standards will catch up eventually. um yeah and speaking of on-chain stuff uh i think it's very cool to put as much as possible on chain and like this for example the compiler itself the front ends and one thing. that's um uh. uh eric who is listening also we're working on uh the online ui together and he built the rss feed on chain. maybe he can do. and a short introduction because i think it's going to be useful for your podcast because you do the rss feeds and if you want to try it out try to have an rss feed on chain. i think that would be pretty cool idea also.

Nicholas: that would be cool eric if you want to do it quick yeah i invited him up but i don't know if he's uh going to be available.

Nazar Ilamanov: yeah if he is oh here we go.

Eric: hey eric hey hey guys oh yeah i was just listening and uh thanks for the uh for the intro there. yeah like the. the short and quick of it is that um you know there's i think you guys are touching on it. there's a lot of experimentation that can be both fun and you know combine web 2 web 3 protocols and rss is actually in a very unique way where you know it can disseminate information across a lot of applications. right now um but there's not really digital authentication baked in. people are still hosting rss feeds on you know various providers whatnot still.

Nicholas: so you're saying the. the challenge you're trying to solve is that rss is not associated with a public address. or what do you mean?

Eric: yeah like i guess so you still have like a third-party hoster for a lot of rss feeds. um but something that would be something i an interesting combination is like being able to have. uh you could basically have

Nazar Ilamanov: a

Eric: signature per episode per channel and whatnot um and so then you can you can really put a lot of uh a lot of data into these xml pages which are the rss feeds and so um i thought that was like a perfect entry point for people being able to have digitally verifiable.

Nicholas: um you know podcast blogs and so forth i guess i guess for most people like for me for example people you know i don't know nobody uh nobody's inserting uh fake episodes into my feed so far. but uh i guess it could be a problem. i i this is the question right like even if you do come up with something that's pretty fun or pretty interesting if it's not novel and people don't have the problem with the off-chain version then they may not be gravitating to it.

Eric: definitely yeah definitely i think there's. there's not like a appeal immediately to you know like why why would i have a second rss feed? it almost might be just like a secondary thing. um uh you could. you know there's always kind of fun things that you could bake into it. i started to think of like um you know you could actually have on-chain subscribers that you know it basically equate to a white list and then

Nicholas: you could

Eric: have like um content that people who are on that white list could subscribe to and you could even hash it and let those people that are on that subscription list. uh decrypted and whatnot.

Nicholas: yeah that is interesting. subscribable content on chain. uh that's of a verified provenance.

Eric: yeah yeah so it's just a it's space. and um nazar and i are talking about it and i thought that that would be like a fun thing to you know fully bake on chain you know have a non-chain primitive. that's like both ui and um back end with the contracts and everything all in one and i think that's it's especially useful for like especially when you're talking about information and how that's released publicly and whatnot.

Nicholas: um yeah great thanks for coming in and telling us about it.

Eric: yeah i appreciate you guys bringing me in. it was fun listening along.

Nicholas: uh well i think we've reached the end of my list of questions. um thanks nazar for coming in and uh telling us all about uh monobase and all the other projects you've been working on.

Nazar Ilamanov: yeah thank you so much for this conversation. it was really fun. uh thank you for hosting me.

Nicholas: for sure if people want to check out more it's monobase.xyz. any other places you want to send them?

Nazar Ilamanov: um my twitter also. uh it's nazar underscore la mano. uh my last name.

Nicholas: uh yeah great i'll put a link in the show notes.

Nazar Ilamanov: we i am uh on the forecaster but i don't spend that much time.

Nicholas: i should be spending more all right maybe in the future. yeah all right nazar eric thank you so much for coming through. thanks everybody for coming to listen. see you same time same place next week. and uh happy holidays.

Eric: happy holidays guys.

Nicholas: hey thanks for listening to this episode of web 3 galaxy brain. to keep up with everything web 3 follow me on twitter at nicholas with four leading ends. you can find links to the topics discussed on today's episode in the show notes. podcast feed links are available at web3galaxybrain.com. web3 galaxy brain airs live most friday afternoons at 5 p.m eastern time 2200 utc on twitter spaces. i look forward to seeing you there.