BGP Blockchain
rfc-editor.org
rfc-editor.org
- Blockchain is just an inefficient linked list/database
- Merkle Trees have existed since the 70s
- Distributed systems have existed since the 80s
- ZK proofs have existed since the 80s
Completely disregarding any advances in cryptography or consensus. Usually they throw in a reference to some other unrelated consensus algorithm like Paxos or Raft to seem smart.
And if you attempt to highlight some advances in the DLT space, you will be accused of "spouting buzzwords". There's literally no way to communicate with a person who has already decided they don't care.
Hm, I think it's not because people don't care, but rather because "blockchain" is (for many people) inextricably linked to shady fintech assholes that actually don't care about interesting technical concepts and intricacies behind DLT.
These people are probably the most condescending, obnoxious, ignorant douchebags that I have ever met in my entire life. My confidence in DeFi shot up tenfold after meeting these people
I said unrelated, not untested. Raft is not an adversarial protocol, it doesn't share the same threat model as blockchains.
They fulfil entirely different purposes.
Do you think that argument structure is sound? By that logic quantum computing is a scam, because quantum theory has existed for a century.
For every thoughtful and educated comment I receive about blockchain technology, I get more than twenty that either make very basic mistakes in understanding the current state of it, take personal offense to me even daring to suggest that blockchain technology isn't completely useless, and/or repeat tired tropes that apply only to the specific design of Bitcoin or have otherwise been overcome by the technology's progression over the last decade (e.g. energy usage, scaling, the oracle problem).
Because money is involved, everyone feels like they have to have an opinion on it, even people who have no background in blockchain system design. As a consequence, informed discussions about this technology seem to be a real rarity.
Because it is actually useless. I've seen tons of people trying to explain the current state of it and a lot of them do the exact same thing but in reverse: falling back on very basic mistakes made by the specific design of Bitcoin and taking that as a given of how they need to design systems. Everyone who talks about energy usage, scaling, and the oracle problem in this way is missing that these problems could have been entirely avoided by just not using blockchains in the first place. The sense of struggle and "progression" here is entirely made up. You're repeating the same mistake as the critics by even talking about these things. The fact that the discussion is even framed in these terms as if these problems need to be solved in some particularly obscure fashion is a net loss for everyone involved, including you.
I've seen a lot of people make that mistake too. A whole ton. But you can't tell me that you form your opinions on new technologies based on listening to people explain them poorly and try to shoehorn them where they don't belong.
> Everyone who talks about energy usage, scaling, and the oracle problem in this way is missing that these problems could have been entirely avoided by just not using blockchains in the first place.
They could have been avoided, yes, but someone chose to solve them so now they're solved. I don't really understand your point. Are you saying that nobody should have been allowed to solve those problems?
> The sense of struggle and "progression" here is entirely made up.
It's unclear to me what you mean by "sense of struggle". But a decade ago the technology had several unfavorable properties and limitations, and now it no longer has those certain unfavorable properties and limitations. Is that not progress?
> You're repeating the same mistake as the critics by even talking about these things.
What mistake am I making, why is it the same as blockchain critics, and why am I making such a mistake by talking about the quality of the forum discussions I participate in?
> The fact that the discussion is even framed in these terms as if these problems need to be solved
I don't frame things that way; I don't view most things in the world as "problems needing to be solved". What I do see is processes that can be streamlined through the use of certain technologies.
I don't necessarily believe that this RFC is helpful, or that blockchain is a useful technology in the context of BGP, but you're making a sweeping statement about the nature of all discussion of blockchain technology, a statement that I believe to be overgeneralized and essentially incorrect.
> in some particularly obscure fashion
Many of the systems that blockchains aim to improve on are already particularly obscure. Naming systems, ownership registries, and financial derivatives come to mind.
But more fundamentally, the complexity of a system's software implementation does not directly correlate with its utility as you seem to imply. Plenty of software projects out there are very complex, yet still manage to be very useful.
> Because it is actually useless.
None of your comment really supports this conclusion.
Because those advances exist in spite of blockchains. I wish blockchains were a useful technology, but they actually aren't. I've seen zero advances in distributed ledgers that are actually helped by blockchains. The use of a blockchain strictly makes it worse. And even past that I've seen very, very few situations where the whole idea of a distributed ledger even makes sense to begin with.
If you want to communicate a way this technology is useful then just do it and make me care, don't waste time going on about merkle trees and consensus algorithms and getting sucked into the same reductionist trap of singling out some minor technical details.
I purposely didn't, because then I'm committed to defending dozens of attacks. I already do a lot to educate people on DLTs on several platforms. I'm not gonna turn HN discussions into my full-time job.
If you don't like it, you can fuck off.
They won't go away that easily. They are really waiting for the next crypto scam / Defi hack or Ask HN about blockchains or crypto to be posted before doing so and it's very predictable.
Anything about posts like this [0], you won't see them.
[0] https://stripe.com/blog/expanding-global-payouts-with-crypto
To be fair, blockchain-like technologies can be extremely useful for improving Internet security. See, for example, certificate transparency. (But note that CT does not involve mining and barely involves consensus. I could imagine requiring something like CT for BGP routes, but I could also imagine it going horribly wrong in the event of a need to recover from failure.)
https://www.sciencedirect.com/science/article/pii/S240595952...
https://ieeexplore.ieee.org/document/8751229
I’m pretty sure there are non academic projects too but I can’t find them atm.
No. I am saying even one of the worst designed specifications with tons of flaws and hype around it somehow made its way into being an RFC and still being used all over the internet for sessions [0] with many reasons why it is a critically flawed RFC. [1]
[0] https://apibakery.com/blog/no-jwt/
[1] https://paragonie.com/blog/2021/08/paseto-is-even-more-secur...
As opposed to living nowhere?
Why?
One does not "simply take over majority control of the network".
Edit: Looking at the votes, it seems like I may be the only one who it's unclear to. Could someone please fill me in?
Construct an appropriate analogy for the bgp use case.
Whereas in a blockchain, if you assume the participants are the same set of actors - which would make sense - then it would be very easy for a majority of network control to be held by a Google, an AT&T, a China Telecom, etc.
Introducing third-parties who are not neccesarily involved in the operation of networks to said blockchain also opens up BGP operators to a whole new raft of attacks. Want to blackhole an ASN? If you can convince a smart contract that the routing policy for that ASN is "drop all traffic" then you don't even need to compromise people's routers or muck around with all that messy DDoS stuff.
Bad, bad idea. Just like 99% of stuff with the word "blockchain" in it.
If the default path of technology were such that our current DNS system were based on a blockchain smart contract system, and then someone proposed a new system with single points of failure, reliant on trusted recursive resolvers, registrar middlemen, a trusted root zone for every country, and a tacked-on CA system that requires fully trusting N-of-N organizations dotted across every jurisdiction on the globe whose job is to verify address resolution from multiple network perspectives, plus OCSP and CT servers to enforce revocations and maintain certificate history - both of which are problems directly caused by a non-blockchain system design - they would be laughed out.
With ENS:
* The blockchain itself is the root of trust, because every name entry has an associated owner entry and every owner entry has a public key entry, which can be used to encrypt and authenticate content.
* Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software.
* Users can register names directly by using a piece of software, without requiring registrar companies.
* The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers.
* In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS.
If you want to go into "extreme detail", now is the time. Please tell me why I am wrong.
No they wouldn't because almost all of those properties are actually desirable, and the only real achievement of ENS is to approximate all of that. Remember that the whole reason you're even using a blockchain (in the Ethereum sense) is because it artificially makes it too expensive for ordinary people to fork the chain. It has no purpose otherwise. If you can come up with a cheaper and more efficient way to do that then there's no reason to use a blockchain. I'll address each of your points.
>The blockchain itself is the root of trust
Which is the single point of failure.
>Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software.
This is not actually desirable, you have no way of knowing whether someone is actually doing this correctly and not sending you fake records unless you use some other trust mechanism.
>Users can register names directly by using a piece of software, without requiring registrar companies.
This is not true at all because most users need to go through a number of middlemen to interact with the blockchain in any way. In practical terms you aren't getting rid of registrar companies by doing this, you're just farming the task out to miners/validators who get paid to run the smart contract.
>The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers.
This is also incorrect, you're trusting parties to host the system on the blockchain which are the "privileged servers".
>In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS.
The solution here would be to just add more redundancy to DNS, blockchains again don't do anything special.
What properties? What I've listed are operational requirements, which blockchain systems have much less of.
Some desirable properties I can think of are reliability, security, and geographic redundancy, all of which a blockchain system could match or exceed.
Getting rid of the CA/OCSP/CT system would be a huge start security-wise, and getting rid of trusted operators for particular TLDs would be helpful reliability-wise.
> Remember that the whole reason you're even using a blockchain (in the Ethereum sense) is because it artificially makes it too expensive for ordinary people to fork the chain. It has no purpose otherwise.
"The chain" is a geographically distributed database, an ideal kind of data structure for keeping track of names. If forked, the database is no longer useful.
The protocol's purpose is to maintain that data structure, which is enough. There doesn't need to be an "otherwise", because that data structure has desirable properties that no other type of protocol can replicate.
> If you can come up with a cheaper and more efficient way to do that then there's no reason to use a blockchain.
I do believe that a blockchain is actually much cheaper and more efficient than the network of thousands of licensed and privileged organizations that we currently have. A proof-of-work blockchain is not more efficient, of course, but a proof-of-stake blockchain is. You could eliminate a lot of jobs in devops and reliability engineering, and replace them with hobbyists running blockchain client software on a home server.
> Which is the single point of failure.
Properly designed blockchains have no single point of failure. The only point of failure is the protocol itself, which you could also say about DNS. Ethereum has had a massive target on its back for many years now, yet has had zero downtime.
> This is not actually desirable, you have no way of knowing whether someone is actually doing this correctly and not sending you fake records unless you use some other trust mechanism.
The fundamental purpose of a blockchain is to come to consensus on data without any trusted parties. When you query data from a blockchain like Ethereum, that data is signed off by the network's consensus algorithm, so you can trust that it hasn't been altered. Data integrity is a basic blockchain concept.
On the contrary, it's your recursive resolver in the current DNS system that you have no way of knowing is sending you fake records. As client DNSSEC adoption is effectively nonexistent (and registrar and domain adoption is spotty too), your recursive resolver can send you just about anything. Unless you use some other trust mechanism, you have no idea whether the IP it gives you for a certain name is valid.
> This is not true at all because most users need to go through a number of middlemen to interact with the blockchain in any way.
Not true. People do that because it's convenient, but all you need to start resolving is to download geth and query the resolver contract. You don't need any middlemen.
> In practical terms you aren't getting rid of registrar companies by doing this, you're just farming the task out to miners/validators who get paid to run the smart contract.
That's true, but a swarm of unprivileged computers with an m-of-n trust profile and uptime guarantee is preferable to your registrar with a 1-of-1 trust profile and uptime guarantee. The blockchain behaves predictably as long as m-of-n validators are honest - a company behaves however it wants to, and could throw you under the bus at any point due to incompetence or corporate malice (see the story of "How I Lost My $50000 Twitter Username").
> This is also incorrect, you're trusting parties to host the system on the blockchain which are the "privileged servers".
The trust profile is totally different, though. DNS requires 1-of-1 trust for each TLD. ENS requires m-of-n trust across a swarm.
If one DNS TLD server goes down or defects, an entire section of the internet goes down. If one blockchain validator goes down or defects, the network boots them off (validator exit) and nothing happens.
> The solution here would be to just add more redundancy to DNS
DNS is already very redundant. How would you add more reliability without completely rearchitecting the protocol, or adding a concept of "a chain of blocks of data" that registries pass around and vote on the validity of?
> blockchains again don't do anything special.
We might have to agree to disagree. I think it's self-evident that something "special" was achieved, otherwise people would have forgotten about them a decade ago and moved on.
Why wouldn't one just design such a system to give each entity equal sway over the network? One entity, one vote.
I think you would need something like a web of trust (each entity is responsible for the actors they vouch for). Otherwise, some kind of proof of how many users they represent.
A hard-coded initial entity set, along with a voting process for additions to and removals from that entity set.
In other words, a classic DAO design.
Like most BGP security proposals, it suggests that you could validate that BGP announcements come from the owner of the prefix. Unlike most BGP security proposals, it lacks any specific mechanism to do so ('store it in a blockchain so ISPs can get the data' is insufficient - where is the description of the data format, the mining incentives, initial chain seeding, etc).
Blockchain solves the problem of distributed consensus in the presence of unknown actors. However, no ISP is peering with an unknown actor, and distributed consensus between mutually trusting parties can be solved far more simply than a blockchain.
BGP absolutely needs a mechanism to validate ownership of the prefix you are announcing. At its core, that means a list of prefixes and the public key of the owning institution, plus a signature field in the BGP packet. The interesting bit of any BGP enhancement is the governance of changes to the list of prefixes and keys.
Doesn't that sound like a basically valid use case for a blockchain? Not saying that it's necessarily the best solution, but having that governance based on some kind of distributed consensus protocol does sound reasonable, and that's what a blockchain fundamentally provides.
I can't really discuss the particular merits of it, though, because this RFC doesn't deign to actually address any of the interesting or difficult parts of enhancing BGP.
It doesn't even talk about what security properties their proposals would support if they had been written - other than 'more secure'.