I'll be honest I had no idea that access to Ethereum is effectively gate-kept by two centralized entities (Infura, Alchemy). I knew there were only one or two true Ethereum full-nodes, but the impact of that never quite clicked.
Me either. I had no idea that accessing a link to NFT-described content went through OpenSea for content that isn't even hosted by OpenSea. That's apparently a MetaMask thing. Supposedly a MetaMask wallet can connect to any willing node, but in practice they use the Infuria->OpenSea server.
Yes, you can run your own Etherium node and server, and connect a MetaMask wallet to it.[1] As Moxie points out, nobody wants to do that.
Worse, the blockchain does not, apparently, contain the hash of the data. You can't even prove you even have access rights to the data if the hosting service goes down. All you own is a link to a URL.
There are more Ethereum full nodes than two, but how many will accept web queries? That's a service.
> Worse, the blockchain does not, apparently, contain the hash of the data.
It very often does, and it is certainly the case for most high-value NFTs. It is indeed not the case if you create your NFT on OpenSea and do not take the additional step of freezing the metadata.
Also, there are many artworks that change, so a hash to a single file is not necessarily the right solution.
So if you purchase an NFT, you need to make a local copy of the actual data? Since the blockchain only has the hash? And if whatever server you originally got the data from the NFT for went down, you'd lose it if you didn't make a backup?
In those cases does the blockchain still have the URL as well? And you might end up with a collection of bits that matched the hash in the blockchain but was no longer at the original URL? What's the next step then?
(The "artwork may change" bit seems like it becomes even more weird and potentially nightmarish edge-case/potentially-losing-your-purchase-wise.)
> So if you purchase an NFT, you need to make a local copy of the actual data?
If you purchase one that’s worth say >4 figures then, yes, yes you should! Also at that point, you’re either part of the 1% or at the very least owe some due diligence to your investments.
In reality, the internet is a big copy machine and you’re probably safe. But you should still back it up.
the data has no value. anyone can right click copy an image. the value is that you own the blockchain address that points to a url. picture of a house = no value. deed to the house = value. even if the house is destroyed (data changed), the deed still has some kind of value
A URL pointing to nothing with no way to view the art that supposedly lives there anymore? I don't think that "deed" is gonna be worth much for long.
Sounds like it has the same value as saying "I used to own this one famous painting before it burned down in a fire."
A hash corresponding to the bits in your file? Sure, that works, you can say "yep, this is the image, I own it." A URL plus a hash + the bits. Sure, that makes sense, even if the URL goes away, you can prove that those particular bits belong to you. A URL that's now dead and nothing else? Nah.
You're not getting it. This is a game where the point is to collect deeds to houses, not the houses themselves. What's valuable to NFT enthusiasts is owning the deed to a famous home, even if the home is destroyed. Like saying you have the deed to Lincoln's first cabin
You can say that this is a stupid game and people shouldn't be playing it. I didn't make it up and I don't take part in it. I'm just trying to tell you what they're doing
This is leaving out the real reason: they hold lots of Ethereum and were concerned that not enough people wanted to buy their tokens. So many NFTs have been made under suspicious circumstances that I wouldn’t take the stated goals at face value.
Many NFTs are hosted on IPFS. If someone hosting it pulls the image, you can just start hosting it yourself instead, and since IPFS urls are based on the hash, it will never be "lost" so long as at least 1 person still has the content pointed to by the NFT.
IPFS is basically Bittorrent plus a financing system. Arweave charges US$5/gigabyte for permanent storage on IPFS. This is supposed to be forever, funded by investing the money and speculating in the declining future price of storage.
You can supposedly put academic papers on Arweave's version of IPFS.[1] But if you try "Browse", nothing appears. This acts like another one of those distributed systems that isn't.
I haven't heard of Arweave before, but yes, the [1] link above doesn't show any results either in the "Browse" or "Search" mode. The premise sounds interesting though. Is this a bug of some sort or does someone with more info know what's up?
A deed is to land, the land still exists if the house is gone. Your example is more like owning a title to a car that's been shot into the sun. It has 0 value.
I'd argue you don't even own the database entry. You own _a private key for a wallet that appears in_ the database entry for the hash of the image.
But to truly _own_ something, all the cryptographic guarantees in the world won't change the fact that true ownership can only be enforced through violence. And if your private key can be stolen by hackers in countries without extradition treaties, one could argue that anything digital is only "owned" in the absolute weakest sense of the word: no one has tried disputing it yet.
The centralised marketplaces themselves (like OpenSea) are able to and might try to police duplicate NFTs, or other counterfeit near-matches. I'm not actually sure if they actually do.
But on the blockchain itself, the NFT is just a smart contract (bit of code, bit of data) that knows it's current owner, it's name and a URI pointing at the image. There zero mechanism preventing duplicates.
Hell, it's such an unregulated market that the NFT might be based on a custom smart contract with a backdoor that allows the creator to steal it back at any time.
Ok, yeah, that's what I thought. So someone could sell a multimillion-dollar NFT, then someone else could duplicate it manually and "re-sell" it, and if they didn't do proper due diligence...
Bit that it'd be very practical, but the data itself is shared so in theory every company could set up their own API to render the blockchain into a readable, quick to access format. Even the vanished poop emoji NFT would reappear once someone else renders their view on the blockchain in the right way.
The problem with this is that running servers that store and process one or even multiple blockchains in a searchable way is terribly costly and inefficient. In theory the public ledgers are all safe against locking away data, like Google or Microsoft could do with your accounts in the real web, but in practice nobody wants to be the guy making a loss on serving blockchain views.
If web3 ever gets off the ground, it needs more of these access provider companies. Perhaps even a prebuilt system you can throw onto your own server to participate, like IPFS and other existing decentralised systems provide.
I'm still not clear on the actual benefit of the cryptocurrency web other than the concept of "owning things without legal protection or oversight" which I (and I believe most people) have very little interest in if it comes at the premium it comes at today. From a technical standpoint all of this blockchain stuff is awesome, but it's an awesome solution in search of a problem.
In practice none of this is happening. All the major wallets query OpenSea to determine what NFTs an account has (according to the article). anyone can access the data but that doesn't change what the wallets query. I can start my own wallet that directly calculates who owns what using the blockchain, but that sounds computationally expensive and there's no guarantee that anyone would use it.
"In theory" the data is open. but I believe that the point of the article is that unless I'm running my own node, data visibility is limited to what someone else tells me. and here, in reality, OpenSea has decided to delist the author's NFT and they have no recourse.
Problem is who cares if you run your own servers when everyone you know is viewing NFTs through servers which are manipulating the data like Opensea is.
That's true, but if the NFTs show up on some places and not on others then you could start a "resistance" against the existing market places. Outside of DMCAs and other such legal requirements, an exchange needs to be impartial about the stuff being sold and published on there to remain credible.
The cryptocurrency crowd is usually drawn to the decentralised, unregulated market, and OpenSea has turned out to be the exact thing blockchains are trying to overthrow.
But that's the point. So many people hyping web3 like it's going to be fundamentally different which is why it's worth all these resources (both people and energy), when it appears already heading down the same path as web2. Consolidated companies growing very large and getting a bunch of already known VCs even richer.
It's like a populist movement whose goal is to enrich the existing rich.
And in theory I can build a social network and become bigger than Facebook.
The reality however is that market dynamics, acquisition costs, network effects etc prevent this from happening. And these aren't things that crypto can really solve.
The social graph is 90% of the value of a social network and the hardest resource to build. Without it an exact copy of Facebook built by someone else is useless.
It's only useless if your goal is to have an archival copy of the entire social network. That isn't the goal for most social networks. The build around communities and grow/evolve over time.
It is costly, but not inefficient. This is what we do at my company and our products monetize our blockchain indexing operations. We are doing it all open source and are in the process of decentralizing our operations, so that:
1. anyone who operates a node can contribute time on their node for a share of our revenue
2. anyone can host one of our blockchain crawlers for a share of our revenue
3. anyone can contribute storage to our platform for a share of our revenue
We currently support Ethereum and Polygon, and are expanding to more chains.
I found this an excellent article, but the HN discussion (not calling out your comment specifically) seems to miss the fact that, as programmers, it is fully within OUR power to create the world we want to operate in.
Edit: To clarify - we run our own nodes. Currently on AWS but we are running out of credits soon so soon in our offices and living rooms, and eventually in data centers.
I'm curious what would happen if somebody uploaded illegal data (e.g. child porn, sensitive PII, or government secrets) to an Ethereum contract. Would these nodes be legally required to filter it? If you look at something like the Pirate Bay, it's not simply enough that you are an allegedly content-unaware service -- once you become aware of your service being used for or distributing something illegal, you are required to mitigate it. At the end of the day, these are businesses which operate within a jurisdiction and must act in self-preservation.
But at the point where they start filtering transactions/addresses, there's going to be big questions about what is the true view of the blockchain.
IIRC this happened years ago on the bitcoin blockchain. I guess that nobody seems to care about that data being shared across every full wallet because bitcoin's primary use case is too remote from data sharing ?
In what sense is it "gate-kept"? Isn't the complaint that in practice most people probably use those two services? As far as I know those two services don't do anything to try to force you to use them, and people just use them out of convenience because "People don’t want to run their own servers, and never will."
The potential for single points of failure (or even intentional abuse) does exist because of this de facto dominance of two service providers, but as far as I can tell there's nothing stopping anyone from running their own node and connecting their various cryptocurrency wallets to them other than the money and inconvenience of running your own server.
> As far as I know those two services don't do anything to try to force you to use them, and people just use them out of convenience because "People don’t want to run their own servers, and never will."
Indeed, but one could make the same claim re any Web 2 juggernauts like Google and Facebook. You don't need to use them, sure. You can start your own social network. It's just expensive and inconvenient. This is what causes centralization and gatekeeping in the first place. It becomes self-reenforcing.
Except that you do need to use Google and Facebook if you want to interact with their data. They literally gate-keep the access to their data. It's not just inconvenient to host your own server that discovers peers and syncs the entire log of all historical events on the Facebook social network and allows you to write new events to that log which those peers will recognize. That's impossible (or at least, it would require some significant and very illegal hacking effort).
Heh. “Illegal hacking effort”? In the EU, it's illegal for Facebook to prevent this. In fact, there's even an export button, which gives you quite a lot of the historical data (though not all of it).
To get events, just scrape the Facebook website using Selenium and Python. There are online tutorials for this. Harder than it should be, I'll be the first to admit, but easier than blockchain-based systems. (Blockchain isn't the appropriate solution for social media; use a proper federated protocol like ActivityPub or XMPP.)
That covers exporting one user’s data at one point in time, sure. But you can’t read all public events without significant work on a scraper, and you certainly can’t contribute without going through Facebook’s servers. Of course you’re not forced to use Facebook, but in order to use Facebook you must go through their computer systems on their terms.
But the goal of most people isn't to use Facebook; it's to keep in contact with their friends. Scraping just the things they care about is fairly easy; scraping what Facebook chooses to put in front of their eyeballs when they're using an account (in practice, what they'd see if they were using Facebook) is really quite easy.
Then you can just reply to Facebook messages on something other than Facebook. That'll annoy your friends a bit, but that's the cost of them still using Facebook.
The problem with Facebook is not that it's hard to get your data off. It's not, really. The problem is that you have to be a programmer to do so; and blockchain stuff doesn't fix that problem.
Totally, but as the article points out, you only have the URL. You can't store more than a few bytes on chain so the link can point to a Facebook URL, OpenSea URL, etc which you don't own. So unless you are going to store small messages, what's different?
The concern is that since these companies are iterating faster than the protocol and providing their own API services that apps/products built on these platforms will not in fact be portable, and in practice will suffer from the same lock-in and network effects as web2.
The point is if you buy a stylized poop icon but the pseudo-gatekeeper company deems they want to shut off that part of the blockchain what are you going to do? Are you going to download and maintain 20 PiB of data on a server to keep your unique one-of-kind poop icon? The same could happen in the future to actually valuable things like a contract/NFT between you and another party.
Analysis of blockchain transactions is also consolidating around middlemen too! If you're trying to read data off of the blockchain for professional analysis purposes, you'll find a lot of working analysts are using sites like Dune.xyz, which stick a SQL interface in front of data slurped from the blockchain and charge a pretty penny to access it.
(Wouldn't be surprised if they're slurping from middlemen services themselves)
We have built an open source tool that you can connect to any node (on an Ethereum-based blockchain) and instantly start building datasets about contracts that you care about. All you need is their ABI.
We are committed to keeping this code free. Our policy is only to charge for our operational expertise, but all the code that we use is open source. We are in the process of opening our platform up for decentralization (so anyone can contribute node time, storage, etc.).
There’s no real reason for this to be honest. The Web3 projects I’ve worked on tends to fall for centralized services like Infura because of development needs at first and then it’s just easier to use it for production. I’ve made a decent living for the last two years setting up test infrastructure for Web3 projects due to its complex nature. This is true across all blockchains, not just Ethereum. It’s an area ripe for new DX products.
New products? Would those be more centralized platforms, or is it feasible for me to connect to the blockchain, verify stuff, and so on if I am running my own server?
It still seems that my users on phones and browsers would need to trust me in that case, right?
Oh it’s totally doable to run your own node on your own server! And thanks to the protocols consensus rules your users can trust that for a transaction to go through your node and be accepted onto main net your node is a good actor.
So one example I’d give - every team I’ve worked on has had to build a local development environment with several nodes to easily spin up with a clean slate for deterministic testing. Teams get sucked into tools like Infura to set these up and then it’s so easy to do the same for deployment they do just that. I think there’s tons of room for Blockchain-as-a-Service tools to improve development and testing processes without forcing centralization on main net deployments.
> And thanks to the protocols consensus rules your users can trust that for a transaction to go through your node and be accepted onto main net your node is a good actor.
Usually, you still have the “server is selectively lying” problem; unless the users are talking to each other, how do the consensus rules help with this?
> Usually, you still have the “server is selectively lying” problem; unless the users are talking to each other, how do the consensus rules help with this?
If you're submitting txs to a node that doesn't communicate to the mainnet (they're isolated from it) then any txs that go to it would be void. You could just use that Eth on the proper mainnet as it wouldn't be on the chain. If the node decided to then come onto the mainnet it's chain would be vetoed by the other nodes states and would fork back onto the main chain. Ethereal has Byzantine-Fault Tolerance up to 50% and you don't gain anything by running an isolated node to try trick people.
That's not the only way to lie. You could, for example, lie that a transaction that doesn't exist has gone through – say, in a cross-chain “currency exchange”. Or perform a double-spend attack. Or many other things, because the Byzantine fault tolerance doesn't apply in this case.
> I think there’s tons of room for Blockchain-as-a-Service tools to improve development and testing processes without forcing centralization on main net deployments.
The big Blockchain-as-a-Services shut down - both IBM and Azure are gone.
I don't mean these sorts of simple host-a-node services but something where you can run custom chains for your dev and testing. For example, this week I had to build a separate Polkadot chain for a client that had reduced governance term durations so they only took 5 minutes instead of 120 day and with a smaller council size so tests are easier to manage. This needs to run in CI so has to be in a position to spin up and tear down on command and the genesis block has to fund the appropriate accounts for testing. This could be pretty easily abstracted to a Web App for people to build this without needing to know how the underlying nodes operate, what to change, etc...
It's way simpler to just connect to Wikipedia.org and download the pages you want to read instead of downloading the whole Wikipedia.org database and keeping it stored and updated on your devices. Same principle.
Mostly the cost of hiring a DevOps engineer to set it up and maintain it and taking on the additional risk of having to deal with upgrading the node etc... It's just cheaper and easier to go centralized at the moment.
Though things are never cheaper to maintain than at the beginning of a tech bloom. Its only going to get more expensive to create and maintain as the node and the APIs get more complex.
Sure but these aren't crazy complicated beasts - a binary installation and some unix experience gets you 90% of the way there! I don't think they'll get far more complex in the next few years at least, and documentation/user support is really good
Yes, but with a few other things! Setting up ad-hoc chains with custom genesis files would be a huge improvement for dev teams as they'd not have to make their own solution (which everyone I've worked with has ended up doing).
It's not gate-kept, it's just that it's not easy to run your own node and synchronize to the chain (especially if you're on mobile) so people don't do it and instead decide to trust public nodes.
It's the early days, remember how long the internet worked with http:// ? It's only in 2009 I believe that Facebook switched to https://
I should have said archival nodes, the ones that keep state back to the genesis block. I don't know if that number is even tracked anywhere. I've read estimates ranging from 2 to 5. I'm trying to find where I read that, happy to be wrong - or right, if anyone has data.
[edit] Here. [1] And here. [2]
After examining every which way we could think of to add the Trie state to our Ethereum state, we asked Vitalik for assistance. His first comment to us was “oh you’re one of the few running one of those big, scary nodes.” We asked him if he knew of anyone else running a “big, scary node” to see if we could possibly sync with them. He knew of no one, not even the Ethereum Foundation keeps a full archival copy of the Ethereum chain. [2].
I've run quite a bit of analytics on ethereum and have downloaded the entire chain multiple times for processing and it's freely available from multiple providers. All the major API providers (infura, etherscan, etc) have the all the raw blocks available readily.
Some Erigon nodes run with pruning enabled. You can't tell which ones those are, or how much pruning.
Technically you can tell which Geth nodes are archive nodes with a GetNodeData query over devp2p, although that call is deprecated and will eventually be removed. Its replacement, GetTrieNodes, cannot be used for this.
Archival nodes also keep state back to the genesis block, it's just stored in delta format so you could say that it's not "unpacked" out to the disk. It's a common misconception that "full nodes" don't have all this data.
> Every now and then someone will argue on CT that Ethereum full nodes are not complete nodes because archive nodes exist. I decided to run a little experiment to disprove a few things
> The goal was to convert a full node into an archive node, demonstrating that Ethereum full nodes contain all the necessary blockchain data.
> 28 days later, I can confirm that it worked. I started with a 150 GB full node and expanded it to an archive node weighting 2.3 TB, without external network connectivity.
A full node lets you fully verify the chain's historical states and it lets you interact with the current state. Unless you're running a service that exists solely to allow people to query historical states (like a block explorer service), I don't see why it would be useful to be able to query historical state.
You need an archival node to see a list of all transaction that transfer eth into an address.
A full node can only give you the current balance, and a list of all transactions that directly transfer eth to that address. Any transaction that transfers eth as the side effect of a smart contract is invisible.
I personally see it as a flaw in the design of eth. You shouldn't need the complete history of states just to find all relevant transactions, but you do.
Besides, the argument that regular users shouldn't need to query such information it doesn't change the fact that the information is unqueriable in a full node, short of spending 28 days transforming it into an archival node.
I'll give you that. If you need to query a list of all contract transactions that have ever transferred ETH to your address, I believe you would need an archive node to do so although don't quote me on that.
> Besides, the argument that regular users shouldn't need to query such information it doesn't change the fact that the information is unqueriable in a full node, short of spending 28 days transforming it into an archival node.
If you don't need to query the data, then the data doesn't have to be unpacked and indexed for querying. Seems simple to me.
It's kind of misleading to claim the archival is packed. It's not compressed into some archival format. Instead, the full node contains all the inputs to regenerate the data.
To transform into an archival node, a full node has to rewind to the very first block, and replay every single transaction.
Since the EVM is Turing complete, this is roughly equilvent to stimulating a computer with years of recorded keyboard and mouse inputs, taking care to record how each input effects state of the computer.
You can't jump to the middle, you have to replay the whole thing.
I don't think it's misleading to call Git history "packed", and the mechanism for regenerating historical states is similar to Ethereum's (though of course Git's delta function is changeset-only with no turing-completeness). In fact, Git calls its own delta-storage "Git packfiles".
The EVM is a very simple and rudimentary virtual computer, so replaying the whole thing isn't an impossible task. According to the tweet, it took this guy's computer 28 days to replay 4 years of history.
Git also adds snapshots to the mix, which makes it possible to rapidly jump to fixed points in history and only use deltas for the fine grained seek. Git also has indexes to find stuff.
Git justifies the viability of it's "packing scheme" by actually making everyday use of it.
A full eth node has no snapshots or useful indexes into the archival data. It has to apply the deltas linearly from the beginning. Applying the deltas is very slow, very IO bound, seeking all over the disk.
The data might be there, but it's practically useless. A user who discovers they need some archival data is never going to consider waiting weeks for the nearly 7 years of history to be replayed before running their query. Instead they will head over to etherscan and trust whatever it says.
Those all sound like local database features that one could add to an Ethereum client if they found them useful enough to bother, they aren't protocol-level concerns or "flaws in the design of eth" as you put it earlier.
> The data might be there, but it's practically useless.
The availability of the packed data is useful, just not to the end user of the node. Having this data widely available on the network means that anyone can spin up an archive node by peering with other full nodes, they don't need to discover and peer with the very limited number of other archive nodes, and the network doesn't need to worry about losing that data permanently if all archive nodes go offline.
> A user who discovers they need some archival data is never going to consider waiting weeks for the nearly 7 years of history to be replayed before running their query. Instead they will head over to etherscan and trust whatever it says.
Call me unprincipled but I don't think it's an issue that if a user needs data above and beyond what's needed to fully verify the chain and read and write to it, they're expected to either spin up a more resource-intensive node or retrieve the data from a specialized history service. Statelessness is on the roadmap, so in the long-term the historical data that Etherscan and similar services serve up to you will come with a validity proof anyways.
I'm fine with you dropping the principles of decentralization and accepting that the current situation is ok.
You can construct many great arguments that the increased centralization is a good thing, or that the upsides are better than the downsides.
What I take issue with is attempts to classify ethereum "Full Nodes" as more than what they are. Yes, they technically contain all the information requires to reconstruct an archival node (at least until statelessness becomes a thing).
They are simply not anywhere near the same thing, and attempts to brand them as the more or less same thing just comes across as denial.
> They are simply not anywhere near the same thing, and attempts to brand them as the more or less same thing just comes across as denial.
They are the same thing specifically when it comes to:
* Downloading, verifying, and storing every transaction that has ever happened on the network
* Maintaining a tamper-proof, data-complete copy of the blockchain
* Interacting with the blockchain in a maximally verified, maximally secure way
I never said that they were exactly the same thing or that they should be branded as the same thing, I said that they store the same data (by which I mean from an information-theoretic standpoint), which is true.
> What I take issue with is attempts to classify ethereum "Full Nodes" as more than what they are.
I take issue with the attempts to classify them as less than what they are.
What needs to be squashed is the common idea in the OP that "full nodes are not actually full" because there's a "fuller" "archive" node that has the states indexed on-disk. The difference between a full node and an archive node is perfomant historical queryability, not security or data-completeness.
OP says that "access to Ethereum is effectively gate-kept by two centralized entities", which is untrue because you don't need an archive node to access Ethereum, only a full node. OP's idea that an archive node is the only "true Ethereum full-node" is common baloney that pops up often in the cryptocurrency community.
This is where the difference between theory and reality start to become an issue.
Yes, in theory the full node contains the full blockchain. Yes, it's all you need to verify that any transaction happened. Yes it's tamper proof.
But in reality, it can't show you the full side-effects of every transaction. In reality there are occasionally things things that require archival data. In reality, it's always easier to go to a centralised block explorer, or pay one of the few centralised API services (And I know this from experience, I've synced a full archival node back in 2019, and build a product that required querying it. It was such a pain that these days I'd highly recommend not doing that and just paying for API access)
In reality, the fact that you occationally need to go to etherscan to get the data you need, results in you just going to etherscan anyway, even for the simpler queries when you have a perfectly fine full node sitting there (again, personal experience). Hell, etherscan actually provides more data than an archival node, where else are you going to find the source code for contracts?
In reality... Most people don't even run light nodes. They certainly don't run full nodes. They just use etherscan, or whatever API their 3rd party wallet uses.
That's why in reality, access to ethereum is partially centralised around API providers. Yes, in theory anyone can go around them, set up their own node or create a competing API service at any time. But that's not what happens in reality, and when it comes to the topic of centralisation vs decentralisation, I'd argue that reality is far more important than theory.
Its a bit of a well kept secret. It does not represent maliciousness on the part of Ethereum or centralized node providers - its a consequence of the network doing nothing to compensate for nodes to deliver data to-and-fro. Miners and businesses stand to lose if the whole network crumbles, so the bare minimum is done to supply nodes, which means centralized node hosting.
A fully scalable, sustainable and decentralized network compensates all infrastructure important to the network, which means mining (consensus) and transaction/data routing. A nice side effect of rewarding data transmission is that you incentivize speed, so scalability can happen naturally with no conflicts of interest between miners and users.
Check out Pocket Network, it's a web3 network protocol that incentivizes node operators to run ethereum nodes (and other blockchains). Effectively decentralizes Infura / Alchemy https://www.pokt.network/
It's not gate-kept by two centralized entities at all, there are a lot of alternatives many completely decentralized. This author is clearly new to the space and hasn't really done much research, outside 5 minutes of google.
All these arguments apply to email as well - there are plenty of small providers and you can run your own email server. But, in practice, almost everybody uses gmail or outlook so we still say it's heavily centralized.
What good is running your own full Ethereum node if OpenSea blocks the NFT you're trying to sell and most of the customers who would want to buy it are going through OpenSea's node?
You're not wrong, but it can be a fantastic experience if you do have your own self-hosted node. I run the geth node on a linux server and can connect to it to send blockchain transactions or retrieve information from the chain. Example: my tax prep software took my wallet addresses and found all my uniswap trades by querying the local node.
[edit] By "full node" I meant "archival node."