BGP Blockchain(rfc-editor.org)
rfc-editor.org
BGP Blockchain
https://www.rfc-editor.org/internet-drafts/draft-mcbride-rtgwg-bgp-blockchain-00.txt
68 comments
Seems like they started with ‘How can I apply a blockchain to the problem?’ instead of ‘What is the best way to solve this problem?’. It’s easy to do, focusing on the interesting tech instead of the actual business problem.
They seem to have started there and gone nowhere. This whole document is essentially devoid of content.
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.)
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.)
I don’t even think blockchain counts as interesting tech. Hash functions are old.
hash functions are not what is new with blockchains: its the distributed zero-trust consensus algorithms.
That's what technical crypto skeptics always do, it's one of the most common reductionist comments you can find on technical forums:
- 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.
- 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.
>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.
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.
For the record, I have met with bank directors, managers for portfolios and asset management, etc.
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
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
It doesn't really make sense to put your confidence in something questionable because something else happens to be bad. I get that you probably have a better explanation but this comment isn't explaining it and instead is just taking an opportunity to dunk on people, if you want to have serious discussions don't make any more comments like this. If you really want to improve communication then please do your part to communicate better.
[deleted]
>Completely disregarding any advances in cryptography or consensus
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.
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.
> If you want to communicate a way this technology is useful then just do it and make me care
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.
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.
I bet that you will see the same extreme anti-crypto regulars screaming and crying on yet another blockchain, crypto related post on HN again.
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
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
Have you considered the possibility that the reason you’re not convincing people is that you’ve just got it wrong?
If I was wrong they could just give me a sound argument instead of directing insults at me and throwing "witty" reductionist jabs.
Do you think that argument structure is sound? By that logic quantum computing is a scam, because quantum theory has existed for a century.
Do you think that argument structure is sound? By that logic quantum computing is a scam, because quantum theory has existed for a century.
My experience has been the same as c0mptonFP.
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.
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.
>take personal offense to me even daring to suggest that blockchain technology isn't completely useless
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.
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 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.
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.
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.
You had me until you described paxos and raft as untested.
> until you described paxos and raft as untested
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.
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.
It’s more than that if you want to include consensusless algorithms (see Sui)
The sad thing about this post is that there are much better developed visions of using blockchain as an index for internet routing:
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.
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.
Fyi: This is an "internet draft". Anyone can write one and get it published with little to no review.
It’s also very hand-wavy. Can’t say I learned much from reading the whole document than just reading the title.
Exactly. Just like the deeply flawed JWT RFC when that was first introduced?
I'm not sure what your argument is. Are you implying that every internet draft eventually becomes an RFC?
> Are you implying that every internet draft eventually becomes an RFC?
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...
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...
Does this achieve anything that signed announcements wouldn't?
The announcements have to live somewhere and the idea is to use a shared ledger ie a blockchain.
The announcements are already peer to peer in BGP. Again, what does block chain add that eg, BGPsec (https://www.rfc-editor.org/rfc/rfc7353.txt) does not?
Unless I missed it in that RFC document blockchain adds a shared ledger, as thebeastie mentioned. Aka an unalterable shared record of what changed, when, and by whom.
[deleted]
> The announcements have to live somewhere
As opposed to living nowhere?
As opposed to living nowhere?
This is great! I’ve been thinking a lot about the web PKI and I’m convinced that the future is a blockchain there. The current situation just doesn’t make sense, where too many CAs have powers to mess up and revocation barely work. And sometimes we can detect some of the attacks, instead of preventing them. In the future we’ll have a public registry implemented as a blockchain where browsers will receive light zero-knowledge proof of non-revoked certificate inclusion.
> implemented as a blockchain
Why?
Why?
I pressed CTRL-F in my browser to search for the term "April Fools" in this RFC and I was extremely disappointed that there was no results.
It is not an RFC, it is an I-D (Internet Draft).
Well, after reading a bit of it I can safely say that is completely moronic and it makes complete sense that it was written by someone at Futurewei.
hard pass
I think BGP protocol is an excellent use case for blockchain
Eliding the (at this point frankly tiresome) arguments over cryptocurrency:
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.
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.
>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.
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 don't know about you, but I would prefer it if the security of critical Internet infrastructure wasn't dependent on the popularity of some shitcoin. Which would be necessary, since the distributed consensus depends on the financial motivation for people to spend resources on mining new blocks. You'd need enough random people mining that a government couldn't do a 51% attack.
What makes you think a network like this would be PoW in the first place? It could just be PoA.
If you do it by proof of authority, aren't you just back where you started with some hand-picked set of authorities which have to form a consensus, just like today's internet?
The point would be that you'd have a secure and reliable method to reach, record, and distribute that consensus. Not much of a cryptopunk thing, but a possible useful application of the technology.
You could design one on blockchain, yes.
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'.
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'.
Yes I too have always said the problem with BGP is that it's way too efficient. It's going to be great in the next conflict when Russia simply takes over majority control of the network and reroutes traffic at will and we will all have to go along with it because the longest chain wins.
It's unclear to me specifically what type of attack you are describing.
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?
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?
The internet basically only works because small entities have as much standing and control as large entities. This is also why things like RPKI are required, to prevent small (and large!) actors causing disruption through malicious or accidental configuration of e.g. BGP.
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.
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 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.
Why wouldn't one just design such a system to give each entity equal sway over the network? One entity, one vote.
Why wouldn't one just design such a system to give each entity equal sway over the network? One entity, one vote.
What would stop an entity creating many other entities to sway voting outcomes? This would be referred to as a Sybil attack.
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.
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.
> What would stop an entity creating many other entities to sway voting outcomes?
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.
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.
What would you say are the 1% of stuff with blockchain in the name that aren’t bad ideas?
Don’t bother asking here about anything with the word ‘blockchain’ since not only it is poisonous here, but it is guaranteed to be quickly dismissed without any curiosity of the 1% of applications it may have. Here are a few that are part of that 1%:
[0] https://skiff.org
[1] https://ens.domains
[2] https://impervious.com/beacon
[0] https://skiff.org
[1] https://ens.domains
[2] https://impervious.com/beacon
I'm sorry but absolutely none of those applications need blockchains or even benefit from them at all. If you want to discuss this I could go into extreme detail why that's the case. I can understand being excited about the promises made by them but at some point we all need a good reality check. Having curiosity doesn't suggest any particular kind of acceptance, we can actually accept that something is universally useless and not worth our time. I'm not saying this because I want to crap on people's startups, I'm saying this because they could make a lot better products if they weren't getting wrapped up in this.
I actually wouldn't mind you going into detail about why naming systems like ENS do not benefit from being on a blockchain, as they seem to me to be one of the more obvious use cases.
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.
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.
>they would be laughed out.
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.
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.
> 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.
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.
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.
There is only one valid blockchain at any given time -- the longest one (currently Bitcoin). Any attempt such as this one to create a new blockchain will always be shorter than the pre-existing longer blockchain, thereby making this attempt susceptible to a 51% attack from outside its network.
Bitcoin is not the only valid blockchain in existence, if that's what you're implying (your comment is unclear to me). A blockchain's length (or more specifically, total accumulated work), does not play a direct part in determining its susceptibility to 51% attacks. Furthermore, blockchains are only susceptible to cross-chain attacks like this when they use a proof of work consensus mechanism and also share the same hashing algorithm.
For some definition of "valid". Nobody is stopping you from trusting a different "parallel universe" branch of the Blockchain, you just don't do it because most likely no one else will trust your work and it will be pointless work. Or you do in fact do it because it's a coordinated soft fork (there is a subpopulation that you care about that will together accept this parallel history and reject the mainline history).
Construct an appropriate analogy for the bgp use case.
Construct an appropriate analogy for the bgp use case.
If you fork, don’t you have the same length (at least at the moment of fork), by definition?
You fork a blockchain by linking new blocks on the end (with bitcoin.pdf forming an implicit start node they all kicked off from). Whichever of the forks persuades enough people to continue mining on it becomes the real blockchain and the people will slowly stop working on the other forks. The shorter blockchain will never find enough people to mine it when there's a larger more lucrative blockchain to mine.
Except that it has happened multiple times.