5 ms·

Tim didn't mention a contemporary sibling tech at AWS which should not be thrown out with the bathwater: private (centralized), immutable, signed ledgers. Their

Tim didn't mention a contemporary sibling tech at AWS which should not be thrown out with the bathwater: private (centralized), immutable, signed ledgers. Their version is called QLDB and does have concrete applications where you need an provable audit trail of a stream of transactions with search and index on top. I was on a team at a fintech closely engaged with AWS to prototype a money movement system using that as a central ledger. There's an open source one with similar properties on GH somewhere, also. It's not sexy like blockchain so it seems marketing had to slip in some Quantum to bump the buzzword sex count. If financial industry regulators were serious about catching laundering or book cooking, they would demand this kind of tech as a foundation of compliance reporting.

mariusor 4y ago
Do you have any other clues for finding that open source project? It sounds very interesting to me.
- inkyoto 4y ago
  Hyperledger is one such project: https://www.hyperledger.org/ https://www.hyperledger.org/ (mostly the marketing fluff) and https://github.com/hyperledger/fabric https://github.com/hyperledger/fabric
- imglorp 4y ago
  Here's one https://github.com/codenotary/immudb/ https://github.com/codenotary/immudb/
inkyoto 4y ago
> […] compliance […]. This is the crux of the matter. In a prevailing number of cases, when people ask about a blockchain, they actually want a ledger database with the following properties: – an immutable, tamper proof, append-only transaction log; – cryptographically verifiable datasets; – certification and/or compliance validation by externally accredited auditing bodies for SOC, PCI-DSS, ISO, HIPPA etc. Use cases for ledger databases go beyond finance, and have been becoming a commonplace in health, education, supply change and inventory management, archive record management and similar. Anywhere, where compliance, strict record keeping and/or audit requirements are in place, the ledger databases provide the answer. AWS has QLDB, and Azure will soon have the Azure SQL Ledger Database (built on top of their SQL Server product). Fully fledged blockchains are not required in most cases.
- hanniabu 4y ago
  We want permissionless, which requires decentralization, which requires blockchain
  - LilBytes 4y ago
    For what purpose or enabler does permissionless benefit this use case you have in mind? Or in another way, what does requiring permissions block your use case?
    - hanniabu 4y ago
      I don't want people being able to dictate if I can or can't use a service or to be able to cut me off
- jillesvangurp 4y ago
  Ledgers are quite easy to build. Git is a ledger. It doesn't use a block chain but it does link commits via their hashes; which makes it an audit proof ledger. Unless you can break the hashes, you can't modify its history. And git is used between many different developers and companies working on the same projects. It was actually designed for this use case. The reason git doesn't need blockchains for this is because it funnels all the commits and pull requests through trusted code owners: people. The consensus model is very simple: a mutually respected developer has looked at the thing and gave their thumbs up. Banks, insurers, etc. use ledgers. But mostly they lack cryptographic safety. And they use a similar reputation based consensus model. Auditors, regulators, accountants, etc. It's good enough but the failure modes can be somewhat expensive. And of course the flaky nature of the whole system actually represents a business opportunity in it self. Banking is a very lucrative business. Blockchains are potentially a nicer/cheaper technical alternative for all this. But so far not an essential or very practical one. And of course most block chains have scaling challenges. Ethereum is a non starter for running anything at scale. Transactions are too slow, too costly and the throughput sucks. Even with the new version it's still nowhere good enough to run even a small bank. Highly unsuitable for running millions of accounts on where the cost of each transaction would far exceed the value of that transaction.
fulafel 4y ago
The analogy to git comes to mind. To match the above you'd need to be using it with signed commits. In the Git world there's the debate about rewriting vs preserving history. The similarities might be actually interesting. In Git users there are two schools of thought, one which advocates preservign history (even if it is messy / involves fixes) because preserving a record of what actually happened is useful [1]. The other insists that a curated version of the history is more important because it is easier to understand in retrospect. [1] There are other downsides in Git history rewriting, such as the blow up you get when attempting to merge / join branches where one has rewritten history and the other not... and the blow up you get when two people attempt to collaborate on a branch in presence of rewriting. These might have accounting analogies too
Terretta 4y ago
Read tbray's article looking for QLDB. There were keywords along the way suggesting the possibility, but it didn't get there. As a NYC financial services CTO, a few years back I spoke to Jassy personally, asking him to please not make 'traditional' blockchain nonsense, but to please productize and release a distributed ledger primitive. A few weeks later, AWS got back to us and said they were willing to work on such a thing, and a few groups (perhaps such as yours) jumped on as well. In our case, we were looking to use it to help manage multiparty contracts where we as a bank were trusted by the multiple parties who didn't need to trust each other. When AWS did eventually* announce AWS Blockchain at re:Invent, they announced QLDB alongside. One was what everyone was begging for, one was useful. I'll leave which is which as an exercise for the reader. :-) TL;DR: I encourage anyone serious about solving financial services problems where blockchain comes up to look at QLDB instead, but also anyone looking at security, compliance attestation, or other multi-party trust or regtech related problems. * Note: "eventually" as in, quite late to the blockchain hype party, and dragged kicking and screaming by the sales org, as tbray describes, so that at least they'd stay in the room with "big IT" signing up for IBMs hyperledger and other failed experiments.
jiggawatts 4y ago
Azure has something similar as well: https://learn.microsoft.com/en-us/sql/relational-databases/security/ledger/ledger-overview https://learn.microsoft.com/en-us/sql/relational-databases/s...

mariusor 4y ago

Do you have any other clues for finding that open source project? It sounds very interesting to me.

inkyoto 4y ago
Hyperledger is one such project: https://www.hyperledger.org/ https://www.hyperledger.org/ (mostly the marketing fluff) and https://github.com/hyperledger/fabric https://github.com/hyperledger/fabric
imglorp 4y ago
Here's one https://github.com/codenotary/immudb/ https://github.com/codenotary/immudb/

inkyoto 4y ago

> […] compliance […]. This is the crux of the matter. In a prevailing number of cases, when people ask about a blockchain, they actually want a ledger database with the following properties: – an immutable, tamper proof, append-only transaction log; – cryptographically verifiable datasets; – certification and/or compliance validation by externally accredited auditing bodies for SOC, PCI-DSS, ISO, HIPPA etc. Use cases for ledger databases go beyond finance, and have been becoming a commonplace in health, education, supply change and inventory management, archive record management and similar. Anywhere, where compliance, strict record keeping and/or audit requirements are in place, the ledger databases provide the answer. AWS has QLDB, and Azure will soon have the Azure SQL Ledger Database (built on top of their SQL Server product). Fully fledged blockchains are not required in most cases.

hanniabu 4y ago
We want permissionless, which requires decentralization, which requires blockchain
- LilBytes 4y ago
  For what purpose or enabler does permissionless benefit this use case you have in mind? Or in another way, what does requiring permissions block your use case?
  - hanniabu 4y ago
    I don't want people being able to dictate if I can or can't use a service or to be able to cut me off
jillesvangurp 4y ago
Ledgers are quite easy to build. Git is a ledger. It doesn't use a block chain but it does link commits via their hashes; which makes it an audit proof ledger. Unless you can break the hashes, you can't modify its history. And git is used between many different developers and companies working on the same projects. It was actually designed for this use case. The reason git doesn't need blockchains for this is because it funnels all the commits and pull requests through trusted code owners: people. The consensus model is very simple: a mutually respected developer has looked at the thing and gave their thumbs up. Banks, insurers, etc. use ledgers. But mostly they lack cryptographic safety. And they use a similar reputation based consensus model. Auditors, regulators, accountants, etc. It's good enough but the failure modes can be somewhat expensive. And of course the flaky nature of the whole system actually represents a business opportunity in it self. Banking is a very lucrative business. Blockchains are potentially a nicer/cheaper technical alternative for all this. But so far not an essential or very practical one. And of course most block chains have scaling challenges. Ethereum is a non starter for running anything at scale. Transactions are too slow, too costly and the throughput sucks. Even with the new version it's still nowhere good enough to run even a small bank. Highly unsuitable for running millions of accounts on where the cost of each transaction would far exceed the value of that transaction.

fulafel 4y ago

The analogy to git comes to mind. To match the above you'd need to be using it with signed commits. In the Git world there's the debate about rewriting vs preserving history. The similarities might be actually interesting. In Git users there are two schools of thought, one which advocates preservign history (even if it is messy / involves fixes) because preserving a record of what actually happened is useful [1]. The other insists that a curated version of the history is more important because it is easier to understand in retrospect. [1] There are other downsides in Git history rewriting, such as the blow up you get when attempting to merge / join branches where one has rewritten history and the other not... and the blow up you get when two people attempt to collaborate on a branch in presence of rewriting. These might have accounting analogies too

Terretta 4y ago

Read tbray's article looking for QLDB. There were keywords along the way suggesting the possibility, but it didn't get there. As a NYC financial services CTO, a few years back I spoke to Jassy personally, asking him to please not make 'traditional' blockchain nonsense, but to please productize and release a distributed ledger primitive. A few weeks later, AWS got back to us and said they were willing to work on such a thing, and a few groups (perhaps such as yours) jumped on as well. In our case, we were looking to use it to help manage multiparty contracts where we as a bank were trusted by the multiple parties who didn't need to trust each other. When AWS did eventually* announce AWS Blockchain at re:Invent, they announced QLDB alongside. One was what everyone was begging for, one was useful. I'll leave which is which as an exercise for the reader. :-) TL;DR: I encourage anyone serious about solving financial services problems where blockchain comes up to look at QLDB instead, but also anyone looking at security, compliance attestation, or other multi-party trust or regtech related problems. * Note: "eventually" as in, quite late to the blockchain hype party, and dragged kicking and screaming by the sales org, as tbray describes, so that at least they'd stay in the room with "big IT" signing up for IBMs hyperledger and other failed experiments.

jiggawatts 4y ago

Azure has something similar as well: https://learn.microsoft.com/en-us/sql/relational-databases/security/ledger/ledger-overview https://learn.microsoft.com/en-us/sql/relational-databases/s...