🏗 What Launched Today at Platform Week?

Hi, everybody. Welcome to Cloud four TV. My name is Wesley and I'm the product manager for research in Web3.

And today, I am so happy to have Thibault.

Thibault, you introduce yourself.

Everybody. Everyone.

So my name is Thibault. I'm a researcher in Cloudflare and focusing on Web3 and web system.

And today we're going to discuss the first announcement we made yesterday regarding Web3.

And Wesley, I will let you go through them.

Totally.

So we're really excited to cap off Platform. We really wanted to talk about where we're going next.

Right.

What are the technologies and systems that are pushing the Internet forward and really interesting ways and Cloudflare we've been working on underlying blockchain technology and Web3 technology for about the last four years now.

I mean, Thibault, correct me if I'm wrong, but we launched the IPFS Gateway in 2018 and Ethereum Gateway in 2019.

So we've been working on this for four years, three years, respectively, for storage and compute, right?

Yes, that is.

And I mean, through the course of these years, we've launched this product.

But at the same time, as part of the research, we like try to innovate and like find new ways and like how to utilize them, make them more resilient and how to use them like in different ways.

So like there's been multiple announcements through this period.

Like we've announced plans for how to do end to end security for IPFS content, find new ways with like browser extension pinning and also like tiering and like building more relationship with the ecosystem.

Like be sure that like Cloudflare can like better serve and be better connected with the ecosystem to like leverage as much as we can the breadth of our network.

And even beyond.

IPFS and Ethereum, we've been really involved with, like you said, core fundamental research.

So we have a lot of friends at ENS, for instance, we've been deeply involved in running Datalink and a number of thoughts about the future of naming on the Internet and how that might work as well.

But today we're going to be focused on the four announcements we made yesterday.

So the big announcement on Twitter was obviously Cloudflare will be participating in the Ethereum Proof of Stake Network via staking or owning our own validators.

We're also really excited to announce that we're going early access for all Cloudflare customers for our Web3 gateways.

So you can use the Ethereum gateway and the IPFS Gateway today on the Cloudflare dashboard for any of your zones.

And then we have some really fascinating content for what's coming next.

Thibault, you wrote two amazing posts on IPFS, really digging deep into both how to use IPFS in Pages together, Pages being our sort of JamStack solution for how to serve static content, but also really thinking about how we're measuring the performance of the IPFS network and IPFS monitor.

So lots of places to start there.

I think we should start with the EA announcements, though.

Let's talk about that.

So what have we been doing for the last eight months? In September, when we announced that we were going to be putting the gateways through a private beta?

So, since we've started putting the gateway in private beta, we like we're focusing on taking the gateway product like we had been operating for like the last like two and three years respectively in the research team, like make them up to scale and like integrated as part of like Cloudflare core offering.

And really what we've been doing is like making sure that like customers are like were using our gateway.

We're also able to leverage the full suit and toolsets the Cloudflare is offering.

So we're like making sure like they would be able to like have, I don't know, rate limiting that we were able to like have like better caching and control over that.

It would be like able to like introduce and have five rules put Workers in front.

So like there's really more modularity in terms of like what is kind of on top of that.

We've also improved like the performance and like reliability of like these products and really improved the way they were managed.

So like from a research gateway to something which is like product ready with like proper SLA on which like we know we would be able to employ more people.

That's so awesome.

I mean, what we've done, I think is a really great case study in experimenting in a small scale idea, right?

Like, here's how we should run the Ethereum gateway, here's how we could run an IPFS gateway and do those in a really Cloudflare native way, right?

With IPFS thinking about caching with Ethereum, thinking about how we can provide high end SLAs for it, taking time and really being rigorous and thoughtful about how we do that.

And then now we're finally taking those and bringing them to market.

So what are some of the things that people can get excited about with doing with the gateways today?

What are some really great use cases for IPFS or Ethereum? I think it's super interesting for me.

It's like when you can sync, like you can put like Cloudflare Workers like directly in front of, like your IPFS file, so like you can add like more metadata, you can transform data that like is already sitting on like fast and like very quickly like and in the meantime maybe like updates it maybe load balancing between like various IPFS hashes, etc..

And I think that's very interesting because this could be like very lightweight process from the edge and at the same time you could like easily ship to your customer or like modify very quickly like the developer experience that you have.

A similar case was Ethereum somehow because the fact that like you wouldn't have like JSON API if you use Cloudflare Workers that could connect to classic AV like cache, etc., you would very easily be able to like do some index content for your dapp and like provide your own craft should be GraphQL API to customers, etc.

directly ingesting the content that like Cloudflare is providing to you.

And really this integration between the Cloudflare developer platform and the APIs that are provided by the WEB3 tools.

I do think something very interesting, exciting and I'm already thinking about like some customers like trying to, to leverage that and I would really love to see what's being built in the future on that thing.

No, totally.

I mean, that's what got me so excited about all of this. It's because that single pane of glass, right?

It's not just one part of the ecosystem or, oh, look, I've gotten a Ethereum gateway or I have an IPFS gateway now it's I have an Ethereum gateway, an IPFS.

I've got Workers that can run on top of that and modify payloads and do all sorts of different types of systematic controls on top.

And then I have all of the Cloudflare Security suite, so I've got DDoS protection, I have rate limiting, I have firewall rules.

I can do so many more things than I could previously do beforehand because everything's nicely built into one stack instead of having multiple different tool chains all over the place.

Yeah, I really think that's powerful, especially because you, I mean, in one place you can control like your normal DNS domains, you can control like just various tools that you would interact with the web normally.

And it's like all integrated through like regular APIs that like customers can use today and devs use as well.

So I think it comes back to something that I talked about at Cloudflare Connect last week.

We got a question, you know, what should why should I build a Web3 app versus a more conventional Internet application?

And my answer to that was, I don't actually see a difference in many ways.

Web3, while it's got a catchy name and we love the tech ourselves, is just a big part of the toolbox, right?

You know, Ethereum is part of the toolbox.

IPFS is part of the toolbox.

How can you use these and the correct way to find the best uses for your engines, for your customer?

Right? It's not a dichotomy that has to be an either or.

It's how can I add this to get the right value?

How can I add that to get the right value?

And what I love about what we're doing here at Cloudflare is we're not making it a dichotomy.

We're not saying it's you have to use these toolsets if you're building a conventional web application or you have to use these toolsets if you're building a Web3 application, it's you've got access to all of the tools and you can put them together however you want to build the application that you want to build.

Yep, I definitely agree.

And there's also kind of like the interesting part in that is, I mean, when you think about Web3, there's no like concrete word.

It's like more like a set and like a broad set of technology and it won't be one app like would use a full set.

And it's a similar way that you can think when you're like building a normal web application.

You probably won't use everything that is available because your application may not need that.

And so the fact that like you're able to pick and choose like what suits best you need, like your business, is definitely very important.

Exactly.

Exactly. So let's dive in a little bit beyond the EA.

So we start talking about what might be next on the roadmap.

And we did that talking about IPFS and Pages.

This is something I am super passionate about.

I remember I came to you, I think it was maybe six or nine months ago.

I was like, How could we get the cloud for a blog on IPFS?

Right?

And it's like, I think there are a lot of different amazing ideas or like how do we get research.cloudflare.com on Pages?

And there's been a lot of internal dogfooding and talking about how do we do that?

How do we utilize our own systems to run some of these things? And it's taken us a bit of time to figure out.

So why don't you walk us through just exactly what the IPFS Pages is prototype that you built is.

Definitely.

So when we announced the integration, the Cloudflare was going interplanetary in 2018 and the integration with IPFS.

Basically what happened is like there was data that was sitting on IPFS and we saw people that wanted to access it through like a normal browser, so like a normal API.

And so what happened is like we provided the tool that was able to read content that was like sitting on IPFS and serve it through a normal HTTP API that browsers could access.

And what we're doing now is we like taking the content like you would usually access through like a normal web interface and serving that content through IPFS.

So like we're going interplanetary again, but this time the other way around. And I really think that's amazing because you when you we were serving content from IPFS to like the web, like we had like nice properties because like we could already leverage like platform network to like Cloudflare network and security to serve content to the user.

Now like doing it the other way around, we also bridge the fact that like we have resources that are accessible on the web and through like normal medium and we give them the properties that IPFS would provide such as like content, addressable verifiability and the modularity that like you can have in handling those different files.

And so I really think that's something interesting and like models to think about.

For instance, if we like, we're discussing that Cloudflare blog for now, it would be served of like through HTTP.

If I want to replicate, I could use like always online from Cloudflare would be like backed like by the Internet Archive if I want to replicate it myself.

But we need to like have like an, find a tooling such that I can like query like the whole website, don't load it maybe it would be like some page which would be like server side rendered, etc..

With the integration with Cloudflare FPTS and Pages.

I would just have like the root of the IPFS hash, which is secured by a DNSSEC because the blog of Cloudflare is on the DNSSEC.

So I would like probably be able to download the content and reprovide that.

And I really think that something like but also something like at the time, it's like quite challenging to do in the web.

No, it makes total sense.

I mean, just to rephrase it too, it's what we came up with, the gateway was how do we pull information out of the IPFS network and display it to the end user?

What we've now done is finished the other half of the bridge, right?

It's how do we get content onto IPFS in a really effective way and then serve it back to the end user through however, means they want to access it.

And I think what's so powerful about that is we built it all using Cloudflare again.

We thought about Workers and we thought about R2 and we thought about KV and we thought about IPFS, and we're really excited about where this might lead, right?

What's the long term vision here with IPFS and R2? We think that those two technologies are going to play nice together?

I do think they're going to play nice together because like R2 would be like a storage of content.

And so like for a set of assets you could do similar thing, these assets like authentic and so like indexing on IPFS would be like you would be able to query them, but more importantly you would be able to build a map such that like you reduce like the nodes and the duplicates that would exist, you would be able on top of IPFS to like build more complex relationship on top of these objects.

And definitely I think that's something very interesting because you could have.

Some R2 content like by one customer, like you could reuse the content from another customer that would also be exposing data from IPFS and you would not have to like replicate the data as you would do in a normal web application.

You would just like have a, like kind of a similar to like the data that they do have.

And so inherently it's super interesting because you don't have to set up the tool to like re-replicate, rehost, reprovide and pay the cost for that.

You just link to the data and it's available.

Right?

It's more efficient and it leads to that really nice principle of decentralization and DSAL all the content.

Suddenly you have dapps that if they want to work together to be able to serve content out of the network, that's reflected in each other's applications, in each of those interfaces, they have that capability using IPFS and R2.

And yeah, I think you're like pointing to a really great point that it's not only about serving the content, it's also providing tools that the customer, if you want to have like the own backup at some point, they want to serve data from like the old premise, like they have all the customers, all the providers they can do so and really like Cloudflare has been like we would like to pick winners and losers.

We want to be like an interface so that like anyone can use and leverage our tooling because we do like we like providing fast and robustness at the same time, you should be free to like experience with all the tools.

And I do think leveraging IPFS fully extended is a great way to do so and something that you would have to architect if you're using like a normal S3 bucket, for instance, while with IPFS it comes for free, like you just have it by default.

And I think that's really awesome. I think it's amazing and it's this idea that I love to go back to, which is so much of what we're doing is building tool sets on open standards again when there's so many different definitions of web theory.

But what I love is one of my favorite definitions is this idea that we're back to building an open standards, that we're back on building platforms that don't inherently lock you in.

And so what's great about IPFS and Ethereum is that. We're not the sole arbiter of the platform that you're utilizing.

We're simply one means of access to the compute or simply one means of access to the storage.

And you're free to pick and choose how you want to combine different providers together.

And I think that's such a powerful benefit to give back to customers, to be able to choose how they want to structure their architecture and reduce the lock in and focus again on open standards.

And more than that, it's not that we are not like the sole arbitrator, like we cannot be the sole arbiter the way the protocol is designed.

So this also reduces the risk of like us being a central party, of course, want to be like a key part of the story because like with the network that we've built, we do think we have like great performance, an easy way to access these content, but we don't want to be like gatekeeping access to that content.

So building an open standard is definitely the way to go.

Exactly.

I mean, I couldn't agree more as someone who helps build these products every single day.

The thing that gets me so excited about them is the fact that we don't have to design the systems that are going to lock our customers into something and.

What we can focus on is exactly that. How do we build systems that are incredibly reliable but they're not just reliable because of Cloudflare network?

Certainly we think we have an amazing network and an amazing system.

We're not fallible.

That certainly happens all the time.

Cloudflare blog is a great record of just the many different ways of we found bugs and issues and we've worked through them.

But what's great about these systems is that we're not the sole party and that if we were to have an issue, it's immediately easy to fall over to another backup and continue to have that really strong performance and reliability.

So I think there's so many good stories about what's getting built here and to talk about that.

I think what's interesting is we want to talk about performance and reliability.

I think monitoring is something that comes up a lot and we think about these things.

So that was one of the other blog posts we publish this week was the work that you and Pop and others did had done on the idea of studying IP if you want to talk a bit more about that.

So there's been a lot of studies on IPFS like the network because of the the way it started.

Like so like, you know, kind of like the turn of node on the IPF network, often the connect which are popular, etc.

But at least in the position that we've been, we've seen a lot of users and interest to access content that sits on IPFS through a HTTP gateway.

And that's a time usually when it's not to like blank out because it sufficed like of like one Cloudflare node to like fetch the content on ipfs and then like you not able to analyze the data, which is quite interesting because it provides them like a privacy story.

Users that like use the classic gateway to access content if it's very popular, like Cloudflare would still make only one request out to the IPFS network.

So we kind of like hideouts, like how many users are using certain content.

At the same time, we really want to better understand like how this traffic pattern is shaped and like what's our connectivity to like various party and how like the user story is varies like on an end to end and so.

Building these tools to monitor various scenario that happened on the Gateway was very valuable and the work that has been done by the team on that to find a way so that we can like orchestrate those.

An IPF, S.A.

or multiple IPFS node that would store, provide content and interact with the IP network and the front end.

Like a client that like would interact with the gateway is really interesting because we can modify and tune both to, to replicate and do a lot of various scenario as a result happen.

Like kind of like confirming some look of sentiment that we had.

But that's something like that we can track through like the various upgrade and performance that produces the platform.

So being like grounded in the numbers that we do collect has been very, very valuable to get back to like what we've done over the eight the last eight months, it's been very, very, very valuable to see the evolution of these numbers.

It makes total sense, right?

I mean, these start off as research products. Cloudflare Research is a fundamental Internet technology group.

We want to figure out where the Internet might be headed and play around with the technologies and really de-risk them for what they might be.

And I think being grounded in rigorous physical analysis is a key part of that.

You know, when you talk about confirming some of the sentiments that we might have seen, what do we see that was confirmed and what are some of the things that we're thinking about building to help push the network forward?

So do you think that we're confirmed?

I think is it's very hard at the moment to understand if a content is not available on ipfs.

It relies a lot on timeout and just the way IPFS has been built.

There's been great effort on that side to like better understand what content is stored and where it is available.

And definitely that's some part of like projects we're looking for.

Another thing is in terms of like naming content on IPFS, so IPFS content by default has like this big hashes and like that would change and like that are immutable.

It's not very practical when you have like an application.

So usually you tend to name the content either via like an IPFS name or like a DNS name or like a similar method.

And what we found is like not all of these naming methods are kind of like created equal.

Some of them are like a lot slower to update or to query than others.

So far, the best we found was to use DNS names.

And because it's I do think the way like the protocol had been implemented and etc.

or really had like 20 years to implement like maybe more to implement like this content.

So like they're really like optimized, refined PNS, are definitely like some movement in the right direction to make it faster, but it is still very slow to update, especially if you're like a truly connected node.

And so that's an area where we would like to see improvement in some of like the properties that is provides because every content is signed by Node, which DNS inherently doesn't provide by default if you're not using DNS.

Right.

So it makes DNS like a key part of the story, then.

I know you mentioned that as part of what we're doing with IPFS and Pages, do you just want to cover what DNSSEC is for those who might not have heard about it before?

Yes, definitely.

So DNS started out at a time where the web was like still early and security in like, like trust was not like that widespread.

And so like at that time when you were requesting content from like DNS resolver, the DNS resolver returns you some data, but you had no way to verify that the data is actually what the the owner of the domain intended to serve.

And so DNSSEC in short, comes in that when you receive the content from your DNS resolver such as Cloudflare, you are also able to verify and validate that the data that is being served to you is actually legitimate.

And that's very handy for IPFS because you have like all this system that has been engineered so that you request the content and you're able to validate as the content is shipped to you that it's actually the valid content.

The thing is, if you requesting a particular name and you have no way to see that like the name is associated to actually the content that you want to fetch.

This whole system breaks down. So really having DNSSEC enabled for your IPFS name, for your IPFS content is really important.

And so that's why at Cloudflare, we do think it's a key part of the story.

And this is the part of the story that I love, right?

Because it goes back to that.

It's not an either or conundrum.

It's a really foundational piece of the Internet, DNSSEC, being combined with a next generation technology like IPFS, being brought together and they're not antagonistic opposed to each other, they're building on each other and they're reinforcing each other's inherent protocols.

That's so much of what I love about this story is.

The Internet continually evolving and stitching itself together with open standards and open systems to make itself more secure and more performant.

That's just a it's an amazing thing that's happening.

Yeah, definitely it is.

And I mean is not building nothing like there's already things that happened in the past.

And so definitely interacting and leveraging tools that like have already been like widely deployed.

Both is great because you don't have to redo like overnight analysis and that work, but also it's already shipped to like millions and billions of customers.

So you can already leverage that user base.

Totally.

So let's talk about something that is definitely dyed in the wool in Web3 technology, which is the staking announcement we made yesterday.

So we made the announcement that Cloudflare is going to participate in the security of Ethereum by really helping to secure the network by running proof of stake validators.

So let's talk about what that means, right? Because there's a lot in that.

You want to talk about what the difference is. Well, so many people may know that Ethereum is proof of work today and is heading toward proof of stake.

Do you want to talk about what that transition is called, the merge, and why it's important for us?

Yeah.

So in short, Ethereum for the last six years, seven years, has been operating on a proof of work consensus model, meaning that in order to validate and seal blocks, you needed to perform a cryptographic challenge that required you to use a lot of compute in order to seal the blocks.

And of course, that was like, okay, at the beginning when there was like little, like little activity and like a limited number of nodes and capacity on the Ethereum network.

However, as time passed by, there was like a lot more interest into Ethereum.

The price was driven up and the usage was driven up.

And so as part of that, they were like even more person and like entities that were interested in actually running miners that would perform these challenges in this compute in order to, at the end of the compute, be rewarded by newly minted Ethereum.

Ethereum having value in like the price going up, there was like even more incentive to continue.

However, because only one entity can get the rewards, all the computation performed by those entities was basically going to waste.

And so the transition from proof of work to proof of stake is to say that instead of like having everyone on the network or like the miners do this expensive computation, it would use like an alternative model where people that actually want to validate and seal blocks on the network would put some of their own money up front to say, I will actually validate only like good transactions and if I'm wrong, you can take the money and I'll lose it.

And so this transition is very important because instead of like using more and more computation and resources, should be like in terms of like energy, hardware, etc., you would just use like say like state your interest into like operating such validator, being online, validating like the data of the chain, but you would not add more compute as the network scribe.

So, I think what's great about this is.

When we say proof of work, when we say proof of stake, what we mean at the end of the day is a security model, right?

It's a trust model.

It's how do we create a world in which we have a really, really high security and have really, really high trust?

The data that we see on chain is valid.

And what I love about proof of stake networks is that in the shift of them, not only are they more energy efficient, but Cloudflare can do two really important things here.

I think the first is where security and performance come in. So the first is this hits two things.

By running proof of stake validators, it allows us to help increase the security of the network by running more validator nodes, which we want to have as many nodes as possible.

Right. There's not a theoretical cap on a theory for how many validators you can have.

The more validators, the better to really help increase the security of the network.

The second, though, is performance.

And I think this is really where we don't talk about performance in terms of transactions for a second, but we can talk about a performance per mettle.

So really getting into the nitty gritty and doing the research on what's the energy consumption like of running validator nodes.

Are there ways to tune them?

Are there ways to run them at scale to make them more energy efficient while making sure we have high network performance?

I think there's a lot of really cool foundational research that we're going to do here with this system to help contribute back to the Ethereum network.

And at the end of the day, it also helps increase security so that when Ethereum eventually does go proof of stake with the merge later this year, hopefully that our customers that are running Ethereum nodes themselves or running their gateway traffic through us, that they're running them at the end of the day on an EVM or the Ethereum virtual machine, that is the highest possible security and the highest possible performance.

And also saying through this effort of like training validator nodes, it's like Cloudflare is like already has developed tools for like monitoring, observing and etc., which is something when you're running like a validator node at home may be a bit more tricky.

And so like definitely providing like validator node, like DCIM network and like leveraging the infrastructure that like we have already built also allows us to like experience with like more diverse toolset, be able to like not run maybe like a majority client, but like run multiple clients so that we know that the network would be more resilient at the end of the day.

So that's really like something using the learning that we have is great also for the health of the ecosystem.

I think the other nice thing that when we talk about this too right now, I think it's an easy jump to make that there may be a lot of nodes in highly centralized locations.

Certainly Cloudflare is a centralizing force on the Internet. But what's nice about our Edge network is it's so geographically diverse.

I think one of the major goals with how we want to run validators is to run them in a widely dispersed area so that there's geographic distribution inside the network, too.

That helps prevent a lot of different things, but mainly zero day disasters, where you may lose an entire data center, for instance, and that could take down Y number of nodes quite significantly.

So lots of really cool stuff here happening in the staking world.

I know we only have one minute left, so any final thoughts you want to toss out there to the world?

I think any final thought is like I'm excited about like the future shaping up and like the interaction, like we would be making to like the web and like future protocols that like, might help to, like, enhance its security availability to the end user.

Awesome.

Thank you so much Thibault for being with us today. We're so excited to keep talking with you all about what's next.

Keep an eye on the Cloudflare blog and Cloudflare TV.

Lots of really cool Web3 stuff coming your way later this year.

Thanks Thibault.

Thank you, Wesley.