5 ms·

It's missing the point in the sense that plain SQL has properties that are not desirable for blockchain's (valid) use cases. Consider Git. Git could be implemen

by darawk 8y ago

It's missing the point in the sense that plain SQL has properties that are not desirable for blockchain's (valid) use cases. Consider Git. Git could be implemented using plain SQL, but it's not. It's not implemented with SQL because SQL would be centralized. One entity would have to own the truth of a codebase. This is an unacceptable property for many open source projects, which is why Git was created. The essential use case of a blockchain is when you have something where you want an immutable history, and where, for whatever reason, it is either undesirable, or difficult to converge on a single entity to own that history. This arises in many, many places. Financial assets, source code, legal documents, etc.. It is not that you can't implement say, legal document version control without a blockchain. You absolutely can. But to do so, you have to trust a single entity to warehouse that truth for you. Blockchains are a way of solving that problem, just like Git was a way of solving it for open source.

hobs 8y ago
> It's missing the point in the sense that plain SQL has properties that are not desirable for blockchain's (valid) use cases. Consider Git. Git could be implemented using plain SQL, but it's not. It's not implemented with SQL because SQL would be centralized. One entity would have to own the truth of a codebase. This is an unacceptable property for many open source projects, which is why Git was created. Huh? "SQL would be centralized" At no point is git required to use anything over a network or somehow is more decentralized than a database you pass around and insert data into. A push request is a request to push the same data I pushed into my database into yours, whether its SQL or not makes no meaningful difference.
- darawk 8y ago
  Sure, you can use sql that way. But it's not designed for it. Git is, and so are blockchains.
  - el_cid 8y ago
    But that's exactly how SQL is used?
    - darawk 8y ago
      You push and pull incremental changes between sql databases in a history-preserving way?
      - hobs 8y ago
        If you want to, yeah, pretty much every SQL database supports replication.
        darawk 8y ago
        Yes, but not in a history preserving way, which is why people don't use SQL for version control.
CharlesW 8y ago
> It's missing the point in the sense that plain SQL has properties that are not desirable for blockchain's (valid) use cases. The parent's point is that most of the time it's the other way around, with blockchains being hyped for use cases where they're a terrible fit.
roenxi 8y ago
Git would still be decentralised if it used SQL. SQL would be a language that the git clients would communicate in - git's model would still hold. What makes git decentralised is you copy the entire codebase and then git doesn't treat the original as any more valid than your copy. There are some interesting applications of blockchain in the examples you mention, but they are very case specific. For example, there would be resistance to creating a financial asset where trades can't be rolled back, for example (from governments and probably a number of traders). Legal firms might _like_ being able to destroy documents without leaving a permanent record. With source code we generally have highly trusted groups who are ideal central authorities (eg, I'm only going to get my kernel sources from kernel.org).
- darawk 8y ago
  > Git would still be decentralised if it used SQL. SQL would be a language that the git clients would communicate in - git's model would still hold. What makes git decentralised is you copy the entire codebase and then git doesn't treat the original as any more valid than your copy. You're totally right. We're sort of mixing abstraction layers, here, of course you can implement Git on top of SQL and even SQL on top of Git! (since sql is just a query language + ACID constraints). But I suppose I was more responding to the spirit of the grandparent's statement, which was the traditional usage style of SQL. But you are absolutely correct. > There are some interesting applications of blockchain in the examples you mention, but they are very case specific. For example, there would be resistance to creating a financial asset where trades can't be rolled back, for example (from governments and probably a number of traders). Yes, that is certainly a possibility. However, if I were designing a financial system from scratch, I think i'd probably build in irreversibility at the protocol layer, and then allow institutions to sit on top of that protocol that implement reversible trades by delaying or abstracting settlement on that protocol. I.e. the current crypto model, where 99% of trading happens on exchanges, not on the blockchain. But, when you really do want an irreversible transaction, you bail out to the blockchain and you do it there. I think that is the most sensible model to build a modern, global financial system on. > Legal firms might _like_ being able to destroy documents without leaving a permanent record. With source code we generally have highly trusted groups who are ideal central authorities (eg, I'm only going to get my kernel sources from kernel.org). We do have highly trusted groups who are good central authorities, much of the time. But IMO that is something we've developed out of necessity. It's an artifact of our technical inability to collaborate with trust in the absence of intermediaries. What I think is so exciting about blockchains are their ability to alleviate that trust requirement in certain circumstances. For instance, right now, financial institutions basically are in the business of trust. They do some other stuff too, but their course business is balancing risk and being trustworthy by having scale. JP Morgan isn't going to steal the money in your checking account, because if they steal your $10,000, they put their multi-billion dollar business at risk. So you can trust them not to steal your bank account balance. But what systemic effect does that have? I would argue it has a centralizing effect, not just of trust, but of economics and innovation. If you have $10,000 to put in a savings account, you're not going to entrust it to a bank that only has $20,000 of deposits. Because they have a decent incentive to run away with it! This means that these sorts of institutions have very powerful incentives to grow ever larger, and be extremely risk averse. That is, they are incentivized not to innovate, because innovation is risky, and risk is trust-destructive. Blockchains represent an opportunity to break these sorts of anti-competitive thickets, that rely on this intangible trust-asset to keep out competitors, in very much the same way that the internet helped say, blogs, compete with newspapers, by democratizing distribution. The internet democratized distribution, blockchains democratize trust.
jchw 8y ago
>One entity would have to own the truth of a codebase. This is an unacceptable property for many open source projects, which is why Git was created. What? Git doesn't solve that problem. Git allows peer to peer workflows, but on its own does not provide you with a network of forks or anything like that. For most projects, a single entity owning the source of truth is not only desirable, it's the current reality. And before that, many projects got along fine with SVN and CVS, albiet with less fork friendly workflows. I mean Git definitely enables better development workflows but I don't think it solves or attempts to solve the problem of having a source of truth.
- darawk 8y ago
  Git absolutely does solve that problem. That was one of the major issues with SVN and CVS. The problem that git solved was "how do we collaborate if we don't want a hierarchy / owner?" which is exactly the same problem a blockchain solves.
liamzebedee 8y ago
I’d reframe it in a broader context than a decentralized immutable ledger. I’m lacking the clarity to make a broader statement, so here’s just an example: DAO’s and prediction markets. Both involve in some sense, a form of decentralised governance - where the entity being governed is self-sovereign. A ledger implies we have some functions that apply transactions on rows. A smart contract blockchain (which is a gratuitous interpretation of the author’s referral to blockchain), is more of a collection of self-sovereign entities/systems in the form of programs. While something like a DAO is clearly just a decentralized voting pool, something like a prediction market, which are composed further by other self-governed systems (the validators, the bidders, etc), have micro and macro characteristics for which a ledger-oriented interpretation wouldn’t suffice.
reitanqild 8y ago
> It's missing the point in the sense that plain SQL has properties that are not desirable for blockchain's (valid) use cases. Consider Git. Git could be implemented using plain SQL, but it's not. It's not implemented with SQL because SQL would be centralized. Fossil is definitely not centralized. Fossil is implemented using SQL.
wpietri 8y ago
Right. I understand that blockchains have at least hypothetical use cases. My point was that they are so widely over-used (or worse, invoked by not actually used) that any blockchain advocate can't just dismiss the point mentioned. They have to be clear that they are actually talking about a specific use case where blockchains do matter. I'll note that the three cases you mention aren't obvious candidates for blockchains either. Financial assets mostly work via central registries. Legal documents are generally kept by all parties, as each entity has its own perspective. Source code is usually centralized but sometimes perspective-driven. Blockchains are a possible way to solve some of those problems. But in the 10 years they've been out there, cryptocurrencies aside, I have yet to see a use that couldn't be done more effectively with a better-tested, better-understood technology.

by darawk 8y ago

hobs 8y ago

> It's missing the point in the sense that plain SQL has properties that are not desirable for blockchain's (valid) use cases. Consider Git. Git could be implemented using plain SQL, but it's not. It's not implemented with SQL because SQL would be centralized. One entity would have to own the truth of a codebase. This is an unacceptable property for many open source projects, which is why Git was created. Huh? "SQL would be centralized" At no point is git required to use anything over a network or somehow is more decentralized than a database you pass around and insert data into. A push request is a request to push the same data I pushed into my database into yours, whether its SQL or not makes no meaningful difference.

darawk 8y ago
Sure, you can use sql that way. But it's not designed for it. Git is, and so are blockchains.
- el_cid 8y ago
  But that's exactly how SQL is used?
  - darawk 8y ago
    You push and pull incremental changes between sql databases in a history-preserving way?
    - hobs 8y ago
      If you want to, yeah, pretty much every SQL database supports replication.
      - darawk 8y ago
        Yes, but not in a history preserving way, which is why people don't use SQL for version control.

CharlesW 8y ago

> It's missing the point in the sense that plain SQL has properties that are not desirable for blockchain's (valid) use cases. The parent's point is that most of the time it's the other way around, with blockchains being hyped for use cases where they're a terrible fit.

roenxi 8y ago

Git would still be decentralised if it used SQL. SQL would be a language that the git clients would communicate in - git's model would still hold. What makes git decentralised is you copy the entire codebase and then git doesn't treat the original as any more valid than your copy. There are some interesting applications of blockchain in the examples you mention, but they are very case specific. For example, there would be resistance to creating a financial asset where trades can't be rolled back, for example (from governments and probably a number of traders). Legal firms might _like_ being able to destroy documents without leaving a permanent record. With source code we generally have highly trusted groups who are ideal central authorities (eg, I'm only going to get my kernel sources from kernel.org).

darawk 8y ago
> Git would still be decentralised if it used SQL. SQL would be a language that the git clients would communicate in - git's model would still hold. What makes git decentralised is you copy the entire codebase and then git doesn't treat the original as any more valid than your copy. You're totally right. We're sort of mixing abstraction layers, here, of course you can implement Git on top of SQL and even SQL on top of Git! (since sql is just a query language + ACID constraints). But I suppose I was more responding to the spirit of the grandparent's statement, which was the traditional usage style of SQL. But you are absolutely correct. > There are some interesting applications of blockchain in the examples you mention, but they are very case specific. For example, there would be resistance to creating a financial asset where trades can't be rolled back, for example (from governments and probably a number of traders). Yes, that is certainly a possibility. However, if I were designing a financial system from scratch, I think i'd probably build in irreversibility at the protocol layer, and then allow institutions to sit on top of that protocol that implement reversible trades by delaying or abstracting settlement on that protocol. I.e. the current crypto model, where 99% of trading happens on exchanges, not on the blockchain. But, when you really do want an irreversible transaction, you bail out to the blockchain and you do it there. I think that is the most sensible model to build a modern, global financial system on. > Legal firms might _like_ being able to destroy documents without leaving a permanent record. With source code we generally have highly trusted groups who are ideal central authorities (eg, I'm only going to get my kernel sources from kernel.org). We do have highly trusted groups who are good central authorities, much of the time. But IMO that is something we've developed out of necessity. It's an artifact of our technical inability to collaborate with trust in the absence of intermediaries. What I think is so exciting about blockchains are their ability to alleviate that trust requirement in certain circumstances. For instance, right now, financial institutions basically are in the business of trust. They do some other stuff too, but their course business is balancing risk and being trustworthy by having scale. JP Morgan isn't going to steal the money in your checking account, because if they steal your $10,000, they put their multi-billion dollar business at risk. So you can trust them not to steal your bank account balance. But what systemic effect does that have? I would argue it has a centralizing effect, not just of trust, but of economics and innovation. If you have $10,000 to put in a savings account, you're not going to entrust it to a bank that only has $20,000 of deposits. Because they have a decent incentive to run away with it! This means that these sorts of institutions have very powerful incentives to grow ever larger, and be extremely risk averse. That is, they are incentivized not to innovate, because innovation is risky, and risk is trust-destructive. Blockchains represent an opportunity to break these sorts of anti-competitive thickets, that rely on this intangible trust-asset to keep out competitors, in very much the same way that the internet helped say, blogs, compete with newspapers, by democratizing distribution. The internet democratized distribution, blockchains democratize trust.

jchw 8y ago

>One entity would have to own the truth of a codebase. This is an unacceptable property for many open source projects, which is why Git was created. What? Git doesn't solve that problem. Git allows peer to peer workflows, but on its own does not provide you with a network of forks or anything like that. For most projects, a single entity owning the source of truth is not only desirable, it's the current reality. And before that, many projects got along fine with SVN and CVS, albiet with less fork friendly workflows. I mean Git definitely enables better development workflows but I don't think it solves or attempts to solve the problem of having a source of truth.

darawk 8y ago
Git absolutely does solve that problem. That was one of the major issues with SVN and CVS. The problem that git solved was "how do we collaborate if we don't want a hierarchy / owner?" which is exactly the same problem a blockchain solves.

liamzebedee 8y ago

I’d reframe it in a broader context than a decentralized immutable ledger. I’m lacking the clarity to make a broader statement, so here’s just an example: DAO’s and prediction markets. Both involve in some sense, a form of decentralised governance - where the entity being governed is self-sovereign. A ledger implies we have some functions that apply transactions on rows. A smart contract blockchain (which is a gratuitous interpretation of the author’s referral to blockchain), is more of a collection of self-sovereign entities/systems in the form of programs. While something like a DAO is clearly just a decentralized voting pool, something like a prediction market, which are composed further by other self-governed systems (the validators, the bidders, etc), have micro and macro characteristics for which a ledger-oriented interpretation wouldn’t suffice.

reitanqild 8y ago

wpietri 8y ago

Right. I understand that blockchains have at least hypothetical use cases. My point was that they are so widely over-used (or worse, invoked by not actually used) that any blockchain advocate can't just dismiss the point mentioned. They have to be clear that they are actually talking about a specific use case where blockchains do matter. I'll note that the three cases you mention aren't obvious candidates for blockchains either. Financial assets mostly work via central registries. Legal documents are generally kept by all parties, as each entity has its own perspective. Source code is usually centralized but sometimes perspective-driven. Blockchains are a possible way to solve some of those problems. But in the 10 years they've been out there, cryptocurrencies aside, I have yet to see a use that couldn't be done more effectively with a better-tested, better-understood technology.