6 ms·

Number mobility between Indian telecoms runs on private blockchain. AFAIK it is live and actively used. BC solves a problem there because operating a database f

Number mobility between Indian telecoms runs on private blockchain. AFAIK it is live and actively used. BC solves a problem there because operating a database for that scale would be very complicated. So every telco has their own copy that get synced via a consensus mechanism and signed transactions

joosters 6y ago
You know that a private, or permissioned, blockchain is pointless, right? If some entity controls the blockchain, you might as well just use a standard database.
- ric2b 6y ago
  It's not pointless, it's just yet another way "noSQL" database. It certainly doesn't give you the same benefits of a public blockchain. But if the code is already written, meets the project requirements and is easy to deploy, why not?
  - kls 6y ago
    Because it is a really inefficient way to store what amounts to an immutable ledger in a traditional database. While I don't agree with a lot of the consensus that blockchain is completely useless. I pretty much agree that it is useless if it is owned by a private entity. That was one of the main points of the blockchain, how can we create a public datastore that is not owned by anyone and it tamperproof. I see public blockchain as valuable to freedoms in a libertarian sense but see no value in companies adopting the core blockchain techs. Tooling around public blockchains sure or API's available on things like D'APPS make sense, but private ledgers make absolutely no sense to me. Just use a traditional database and implement all the data storage as a ledger pattern and you get the same effect with out all the energy consumption.
    - ric2b 6y ago
      AFAIK private blockchains usually don't rely on proof of work so there's no large energy usage. I agree that if they're private they're equivalent to a customized database system, private blockchains aren't interesting but it doesn't make them useless, it's simply another way to solve problems that could already be solved before.
    - splix 6y ago
      It isn't owned by a single private company, most usually. But multiple companies with equal rights to update. That's what you cannot do with traditional db. Also I don't think there is any significant energy consumed. There is no mining or anything like that. You have to pay for extra network traffic and more disks, simply because you're going to have more copies of data, most likely, but it's not so large amount of energy.
      - joosters 6y ago
        An API doesn’t care what company the client belongs to, so it’s pretty easy to have a DB that can be updated by more than one company. There’s no technical reason to prefer a blockchain, it’s just marketing.
        splix 6y ago
        It's pretty easy to make it like you said. But it also pretty easy to make it in a way when some companies would have a preference. Second would be more profitable for the owners of that db, so there is a motivation to do it in that way. In many of the countries outside of US/EU it's a popular practice.
smsm42 6y ago
This looks like just a replicated append-only database. One can call it "blockchain" but it's not exactly anything new.
sohamsankaran 6y ago
Reference? AFAIK this was proposed by Wipro in a white paper but was never implemented.
pgo 6y ago
Source for this ? I can only see mentions of plans implementing this, not of it being actually deployed
csande17 6y ago
> BC solves a problem there because operating a database for that scale would be very complicated. Would it, though? Google tells me that India has a population of around 1.4 billion people. Let's assume each person has one phone number, and each phone number requires one kilobyte of number-mobility-related data. Then the database would need to store 1.4 terabytes of information. 1.4 terabytes doesn't seem like an impossible amount of data to store. That fits on a consumer hard drive! Dell will sell you a single server with that much memory! Request volume doesn't seem like a huge issue either, since porting a phone number is something people do extremely rarely.
- mongol 6y ago
  I don't think it is the size that is the problem. I imagine it is like a routing table, keeping track which number is managed by which operator, and if India has number portability, there needs to be a transactional method to update it that is shared by all operators. I could imagine this being done with a blockchain. Or for that matter, recording of call details for billing between operators?
  - deleted 6y ago
    [deleted]
  - csande17 6y ago
    "Keep track of which number is managed by which operator" reduces to "store a small amount of information for each phone number". In a traditional database setup, the "transactional method to update it" would be sending a request to a central server to update the database. The central server can be run by whatever regulatory body or industry association is responsible for number portability -- ideally, this would be the group with legal authority to overrule whatever the computer system says anyway. It wouldn't need to handle a large number of transactions per second because people don't change phone providers very often. You could imagine doing it with a blockchain instead, but you could also imagine doing it using a Yahoo Groups email list -- that doesn't make it a necessary or good solution.
    - 6y ago
Lazare 6y ago
> private blockchain So a database? > AFAIK it is live and actively used. Most things people seem to think are running on blockchain tech turn out not to be, so I'd be interested in any evidence here. Nonetheless. > operating a database for that scale would be very complicated They're already operating a database, so at most this is an argument that a traditional database tech wouldn't work, except... ...this is only a few billion rows, at most, right? With minimal data? It would totally, totally work. We're at a scale where a copy of "MySQL for dummies" is going to explain everything you need to know here. A moderately large number of people in this thread probably work for companies that have traditional databases that work at a larger scale or with higher demands than this.
- an_opabinia 6y ago
  I am not super familiar with the particular example. But if you consider it more like an easy to cluster database with free, tamper-proof backups, it makes a lot more sense.
- redis_mlc 6y ago
  I've worked with MySQL and Postgres databases that invariably include one or two tables with over a billion rows per table. Typically the rows record user fingerprint info of some kind, either UA or location. There is no problem with performance until schema changes are made, requiring a careful migration strategy plan (this is why DBAs get the big bucks.) Source: DBA.
- davidgerard 6y ago
  > Most things people seem to think are running on blockchain tech turn out not to be, so I'd be interested in any evidence here. Nonetheless. There's a few such systems in production - in practice, they tend to use a private Ethereum or Hyperledger as a back-end data store, and 100% of the use case for using a blockchain for your private back-end data store is being able to say "blockchain!" in the press release.
Beldin 6y ago
Number portability in my country is handled without blockchain. Granted, India's population is about 100 times larger. But I don't see a reason why a scale-up with a factor of roughly 100 would be prohibitively problematic.
- splix 6y ago
  Maybe it's not about transaction scale. And I don't really see how blockchain helps with scale, imho it's opposite. With this particular case, it maybe be solution to fight corruption (just a guess). Centralized trusted control of all phone number of a country is a huge power and a magnet for different types of corruption. So maybe the difference is that in your country the magnitude of corruption is lower than in India, or easier to handle because of size.
  - Beldin 6y ago
    > So maybe the difference is that in your country the magnitude of corruption is lower than in India, I don't know about corruption levels in India. I am under the impression that the level of corruption in my country is rather tiny, so this could very well be the explanation.

joosters 6y ago

You know that a private, or permissioned, blockchain is pointless, right? If some entity controls the blockchain, you might as well just use a standard database.

ric2b 6y ago
It's not pointless, it's just yet another way "noSQL" database. It certainly doesn't give you the same benefits of a public blockchain. But if the code is already written, meets the project requirements and is easy to deploy, why not?
- kls 6y ago
  Because it is a really inefficient way to store what amounts to an immutable ledger in a traditional database. While I don't agree with a lot of the consensus that blockchain is completely useless. I pretty much agree that it is useless if it is owned by a private entity. That was one of the main points of the blockchain, how can we create a public datastore that is not owned by anyone and it tamperproof. I see public blockchain as valuable to freedoms in a libertarian sense but see no value in companies adopting the core blockchain techs. Tooling around public blockchains sure or API's available on things like D'APPS make sense, but private ledgers make absolutely no sense to me. Just use a traditional database and implement all the data storage as a ledger pattern and you get the same effect with out all the energy consumption.
  - ric2b 6y ago
    AFAIK private blockchains usually don't rely on proof of work so there's no large energy usage. I agree that if they're private they're equivalent to a customized database system, private blockchains aren't interesting but it doesn't make them useless, it's simply another way to solve problems that could already be solved before.
  - splix 6y ago
    It isn't owned by a single private company, most usually. But multiple companies with equal rights to update. That's what you cannot do with traditional db. Also I don't think there is any significant energy consumed. There is no mining or anything like that. You have to pay for extra network traffic and more disks, simply because you're going to have more copies of data, most likely, but it's not so large amount of energy.
    - joosters 6y ago
      An API doesn’t care what company the client belongs to, so it’s pretty easy to have a DB that can be updated by more than one company. There’s no technical reason to prefer a blockchain, it’s just marketing.
      - splix 6y ago
        It's pretty easy to make it like you said. But it also pretty easy to make it in a way when some companies would have a preference. Second would be more profitable for the owners of that db, so there is a motivation to do it in that way. In many of the countries outside of US/EU it's a popular practice.

smsm42 6y ago

This looks like just a replicated append-only database. One can call it "blockchain" but it's not exactly anything new.

sohamsankaran 6y ago

Reference? AFAIK this was proposed by Wipro in a white paper but was never implemented.

pgo 6y ago

Source for this ? I can only see mentions of plans implementing this, not of it being actually deployed

csande17 6y ago

> BC solves a problem there because operating a database for that scale would be very complicated. Would it, though? Google tells me that India has a population of around 1.4 billion people. Let's assume each person has one phone number, and each phone number requires one kilobyte of number-mobility-related data. Then the database would need to store 1.4 terabytes of information. 1.4 terabytes doesn't seem like an impossible amount of data to store. That fits on a consumer hard drive! Dell will sell you a single server with that much memory! Request volume doesn't seem like a huge issue either, since porting a phone number is something people do extremely rarely.

mongol 6y ago
I don't think it is the size that is the problem. I imagine it is like a routing table, keeping track which number is managed by which operator, and if India has number portability, there needs to be a transactional method to update it that is shared by all operators. I could imagine this being done with a blockchain. Or for that matter, recording of call details for billing between operators?
- deleted 6y ago
  [deleted]
- csande17 6y ago
  "Keep track of which number is managed by which operator" reduces to "store a small amount of information for each phone number". In a traditional database setup, the "transactional method to update it" would be sending a request to a central server to update the database. The central server can be run by whatever regulatory body or industry association is responsible for number portability -- ideally, this would be the group with legal authority to overrule whatever the computer system says anyway. It wouldn't need to handle a large number of transactions per second because people don't change phone providers very often. You could imagine doing it with a blockchain instead, but you could also imagine doing it using a Yahoo Groups email list -- that doesn't make it a necessary or good solution.
  - 6y ago

Lazare 6y ago

> private blockchain So a database? > AFAIK it is live and actively used. Most things people seem to think are running on blockchain tech turn out not to be, so I'd be interested in any evidence here. Nonetheless. > operating a database for that scale would be very complicated They're already operating a database, so at most this is an argument that a traditional database tech wouldn't work, except... ...this is only a few billion rows, at most, right? With minimal data? It would totally, totally work. We're at a scale where a copy of "MySQL for dummies" is going to explain everything you need to know here. A moderately large number of people in this thread probably work for companies that have traditional databases that work at a larger scale or with higher demands than this.

an_opabinia 6y ago
I am not super familiar with the particular example. But if you consider it more like an easy to cluster database with free, tamper-proof backups, it makes a lot more sense.
redis_mlc 6y ago
I've worked with MySQL and Postgres databases that invariably include one or two tables with over a billion rows per table. Typically the rows record user fingerprint info of some kind, either UA or location. There is no problem with performance until schema changes are made, requiring a careful migration strategy plan (this is why DBAs get the big bucks.) Source: DBA.
davidgerard 6y ago
> Most things people seem to think are running on blockchain tech turn out not to be, so I'd be interested in any evidence here. Nonetheless. There's a few such systems in production - in practice, they tend to use a private Ethereum or Hyperledger as a back-end data store, and 100% of the use case for using a blockchain for your private back-end data store is being able to say "blockchain!" in the press release.

Beldin 6y ago

Number portability in my country is handled without blockchain. Granted, India's population is about 100 times larger. But I don't see a reason why a scale-up with a factor of roughly 100 would be prohibitively problematic.

splix 6y ago
Maybe it's not about transaction scale. And I don't really see how blockchain helps with scale, imho it's opposite. With this particular case, it maybe be solution to fight corruption (just a guess). Centralized trusted control of all phone number of a country is a huge power and a magnet for different types of corruption. So maybe the difference is that in your country the magnitude of corruption is lower than in India, or easier to handle because of size.
- Beldin 6y ago
  > So maybe the difference is that in your country the magnitude of corruption is lower than in India, I don't know about corruption levels in India. I am under the impression that the level of corruption in my country is rather tiny, so this could very well be the explanation.