Introducing web3:// – Transforming the EVM into an Unstoppable Decentralized Web Server

Transcript

Hello? Um so So can I can start? Okay. Uh hello everybody. Um so it's my great pleasure to be here to represent Web3URL, uh which turns the Ethereum into a we call unstoppable HTTP server. So a quick intro of myself. Uh my name is Chi. I'm the founder of EthStorage and Kwil. I've been working in this space for more than 8 years. Before that, I was a software engineer at Facebook, Google, working on their infrastructure system.

And so that's why my primary interest in Web3 is in Ethereum scaling in terms of, for example, layer two and peer does. And so we also received a couple of grant supports from Ethereum Foundation, also includes a grant from personal grant from Vitalik. So first of all, uh what is Web3URL? It's a access protocol, which is similar to HTTP, but rather than using centralized, uh for example, domain names and also server, we're using Ethereum as the corresponding server and use smart contract to host the corresponding server-side code to tell what kind of the web front end you want

to display to the users. So uh here is example of the Web3URL format. It's very similar to HTTP, but we replace the corresponding domain uh with the smart contract and also it support multi-chain so that we can put the uh chain ID. And also a way to how to call the smart contract so that we can know how the smart contract would like to uh return the web content by the by executing the smart contract on chain.

Um it's defined in the EIP uh 4804. So it which was uh finalized, I think 2 or 3 years ago. Um so, question, why we want to have this uh protocol? What is the starting point? So, when we develop this uh standard about 2 or 3 years ago, uh we saw there's a great trend of fully on-chain applications, where not only the protocol is uh running on top of smart contract on top of Ethereum, but also a lot of metadata, like front end, images, are also on-chain. So, one particular particular example is uh NFT, where we saw a couple of the NFT projects now

they are moving all of their metadata, including images, on-chain, so that you buy not only just a simple ERC uh token ID, but also corresponding all the assets that can be found on-chain. So, that people can always access this content, rather than uh for example, 4 or 5 years ago, some of NFT images just disappear because it uses a centralized server to host all these images. However, when we take a closer look of all these uh NFT data, um it use third party, uh for example, Moonbirds, which is famous for using uh this images pixels on-chain.

Um if you check this token information, then it still uses a centralized server, HTTP blah blah blah something, to display the corresponding images. Another famous is called CyberBrokers, they upload a lot of vector vectorized uh images on-chain, uh using SVG format. And but you we feel we take a closer look on its image data, it's still using IPFS. So, to our surprise, those data are already on-chain on top of already upload to the Ethereum, they pay half millions or millions of the uh dollars of Ethereum to upload this data, but there's no way on top of Ethereum to access this data directly. So, we still rely on

third-party services. And so, hey, we have to use something new to change this. And that's our starting point to develop this Web3 access protocol. So, the motivation is that with this access Web3 access protocol with a very HTTP-like link, now you can call smart contract and tell, "Hey, what is the corresponding data that you want to display on website?" So, so that we can put in this uh in in the future, for example, in a in a we can put this Web3 URL link and then we can directly grab corresponding data, corresponding images uh from the blockchain network.

Um so, but OpenSea actually also already support Web3 this standard besides IPFS or decentralized servers earlier this year, so that now when you browse OpenSea, actually you will directly find the corresponding images on chain and display to the uh on the front end. And so, to do so, then the corresponding um metadata of this images now can be re- just re- played replaced by a Web3 URL link telling which contract you want to call and what is corresponding info of these uh images, and then it will return those uh images for all these NFTs. And all those links uh actually live on top of the Ethereum network.

Um so, how to use uh I use Web3 URL? Uh actually it's very similar to HTTP inheriting most of the HTTP features, except that we replace the centralized server entities or this thing uh by a decentralized authority. It can be a smart contract address uh hosted by the full address or an ENS name then register corresponding uh address of the contract. And second thing is the a way to how to call the contract so that the contract return corresponding from end data.

Um so and then lastly, uh additional HTTP information that tells what kind of format additional format of this data like for example MIME, and for example error code or couple of other things that you can define in this Web3 uh standard. Okay. Uh so and to use Web3 URL here is uh from user perspective how the Web3 URL will interact. So a user will type the Web3 URL link in the browser that support Web3 URL. And then the browser will uh pass the corresponding information through uh JSON object uh JSON JSON RPC of Ethereum and tells uh what is called in the corresponding address, what is the call data, and how to call the call contract,

return the content. And we know that HTTP is composable uh protocol. So uh HTTP page can contain a couple of the subpages. So the uh this will further turn this subpage calls into future uh further uh Web3 calls for for example of images, a JSON file, and then so this process repeat repeatedly until all the content has been resolved and and then return to the front end of the user.

So for the uh the the relative address resource resolving, this is a basically directly inherit from HTTP so that we can fully power the existing feature of HTTP and well just replace corresponding centralized component with Ethereum. And so how to access this on-chain data with Web3 URL? Um so right now uh we are still working similar way pathway as IPFS. No, now we have a gateway which is open source, so you can run also your gateway. And then and then the gateway will just replace corresponding contra with subdomain and call also corresponding call the link.

And then now you are able to access the corresponding content which will call the corresponding Ethereum JSON RPC JSON RPC is a course for the for the front end. And we also support a basically a Firefox plugin which will allows you to just type this web URL link and then we'll automatically translate to the to the gateway address so that the user can also just directly access without knowing how to translate the web URL to HTTP.

And we also support community project which uh he built a um a a standalone EVM browser so that it can directly on the front end side to directly pass this web URL to corresponding contract call and display play the content. So, this is a super powerful which means that we don't rely on any centralized component just directly at the user side perspective to complete all the display and calls and display all these tasks on the client side. So, it This is kind of a our full goal of fully decentralized access.

Um so, for applications, this can enable a lot of applications. Imagine all the all kinds of applications built on top of HTTP as long as all data is a public, for example, Wikipedia, all kinds of the public information now can be built the corresponding fully decentralized counterpart using our uh standard. So, one one application is NFT images, which I uh also give a example. And I will skip these details. And for example, we also create call personal website uh using web 3 RL, which using smart contract to um simulate a file system. So, that now we can upload the

data like just like FTP, but this FTP actually is a hosted by the smart contract running on public Ethereum. So, that now I can synchronize my local H- HTML data website. Uh this is example of Vitalik website. And on top of the smart contract hosted by the Ethereum network. And now we can access this website without worry about any centralized component that may be compromised. So, this is uh another example that we have already actually running on top of Ethereum mainnet.

And there are more application that exploring. So, for example, one interesting idea is to build a decentralized Git, so that maybe one day uh with the scalability roadmap of Ethereum, uh it both in terms of computation and storage, we are able to uh have the the um Ethereum to host the full uh for example, go Ethereum uh GitHub pages. And so, that now we can develop Ethereum on top of Ethereum without any centralized components. I think this is really cool. Um Um so, um those are right now the current status. And so, we are also have a couple of uh blockers during out the development. Uh one thing is definitely we want more native application support,

especially uh browsers. Uh for example, even though we have plugin, but plugin still rely on some centralized gateway. Um so, we are want to work with um um for example, popular uh browsers. Um actually, there's a couple of engineers from Google. They are really interesting in this idea. They also have a lot of conversation to see how they are able to support this standard. And we also have support from OpenSea already this year. And now it's already fully supported by OpenSea. So that when you browse on chain images that NFTs that with on chain images, then OpenSea will automatically call the smart contract return the data and display the content

for you. Um we also found a couple of issues like there's some malicious reporters saying that oh try to block us and say hey there are malicious content or this thing. Actually this is similar things happens to IPFS gateway. And so just take more time to convince them hey this is a legit thing. We all the things are on chain. And we just like transparently relay all these these data from if they're Um so another issue is regarding the storage. Um so we know that Ethereum is moving towards its new scaling roadmap via increasing the blocks limits of the L1.

Um on the same on the same inside there's also storage issue because Ethereum even they are able to process more transaction via a lot of fancy BAL ZK technologies. But still they need the network to store fully every node should store a full replica of the data. Um so there is also motivation to how we are able to scale this data. Uh especially with the new Ethereum roadmap which we will basically put a lot of data using their peer DAS including block space. Um so we are also working on this direction because it's a storage which received a grant from Ethereum Foundation. And the

basic idea is to build store store native system a layer two storage system on top of Ethereum and uses smart contract to verify the corresponding off-chain storage network. Um and we also the actually the standard is has been also involving. There are a couple of the sub standards that just like HTTP, we know HTTP have tons of the standard that involve HTTP 1 1.2 blah blah blah. So, we are also evolving very quickly. We have a couple of sub standards to support different types of HTTPs. As an example, we can also support like standard HTTP request header and send standard HTTP response,

which is exactly the same you write a HTTP handler in terms of your like using Node.js or using Golang, but here is happens in smart contract. So, we have specified standard so that you can have fully utilize existing HTTP power to do more of the months applications. Um so, that's today that's all the presentation and I would like to answer any questions. Thank you very much. Questions?

Uh thank you for the presentation. So, I see the the utility for the what's read-only content that we can put on chain and we just fetch it from smart contracts, etc. But do you have a vision or idea about write content when you want to update it, sorry? Yeah, that's really good question. So, you know HTTP there have a couple of ways to interact with HTTP. There's a get request, there's a post request, and also delete request. Uh so right now the standard uh is only defined for get request. So basically just return the latest verifiable data from uh for example one example I would like to

highlight is for example the baby frontal attack. The reason is that the baby frontal is uh uh is the server is compromised so that it returns the uh malicious content because there's no way to uh or this the browser does not support way to check integrity. So suppose the website is fully put on chain, then now we are able to uh verify it and also be able to make sure it's always available as long at the same as the Ethereum protocol itself. So that's the motivation. And for the post one, actually because if for the Ethereum like we know we have to send a contract in order to modify the content. So for that sense uh we haven't do a lot of work on that side just more

work said. There's a couple of other standards to say how to use a link to compose a transaction and sign it modify. Um so but that's not uh the major direction that we are currently working on. Hello. Thank you for the presentation. Um I see you you will work with the different browser. What about Brave? You you will work with Brave also? Uh so actually I should put put the the logo there. Yeah yeah. Uh actually we would like to work with them but I think um you know it's it's this uh uh it would be easier to have some like

early adoptions before we convince like those browser. For example I can tell one of the major browser here. When we we talk with them say we have this standard we want to work with you to support it. Do you know what was their response? I don't want to name put their name. They say, "Oh, give me 1 million and I will do it." I was like, "Mhm, I if I have this money, then probably I would put it to more adoption rather than just say, "Hey, uh I I just buy your engineer to support this feature." So, that's the current issue we uh we are facing. Yeah. Okay, thank you. Uh my the extension is why don't um uh build a a browser by default who use the protocol Web 3 uh not HTTP?

Oh. Uh uh uh actually we we have a uh uh community browser uh this one. Um so, it's a prototype to demonstrate now we can use the existing uh kernel of the browser and then with some UI interfaces, now we can do the same thing. But, definitely you should you have to configurate the IBC all this information, but it it works. Yeah. Excellent. Cool. Uh thanks for the all the attending the talk and if you have any question, feel free to contact me off offline and I would love to see how we I can uh make the Web 3 better.