4 ms·

> […] 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

> […] 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.
- inkyoto 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. Easy as an arm chair theory, impossible in practice without a complete rewrite of git from scratch. You are also disregarding the immutability of the data and the append-only property of stored datasets in ledger DB's: the entire temporal history of changes to a document (or a table) must be available in a ledger database. Changes are linked by virtue a Merkle tree, and the content of each node (i.e. revision) can be cryptographically proven to be untampered with. QLDB documentation provides a visualisation of the cryptographic verification process and of a sequence of steps: https://docs.aws.amazon.com/qldb/latest/developerguide/verification.html https://docs.aws.amazon.com/qldb/latest/developerguide/verif... Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. So no, Git it is not easy to build a ledger database out of git if there are strict compliance requirements as I can pull out a revision M out of N revisions of my documents stored in a ledger database, run the revision N through the proof interface and use it in a court hearing as evidence or turn it over to external auditors. And no external auditing body will ever certify a git based solution.
  - jillesvangurp 4y ago
    > Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. Read up on git internals, it's a very elegant and simple design and you seem to assume a few things about it that are flat out wrong. A git repository is in fact a Merkle tree. Every commit is chained to the previous commit via a hash that includes the commit content and the hash of the previous commit. So, git history is immutable. You can't modify commits without breaking the chain of hashes. It's by definition append only. You can of course modify your local copy of a git repository and rewrite history (i.e. change all the hashes). But that makes it incompatible with upstream history. People tend to use this to clean up their local change history before they send it upstream. With the exception of force push (i.e. just overwrite the remote repository), there is no way to merge a rewritten history. In order to merge changes, there MUST be a shared commit with the same history. It's not optional.

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.

inkyoto 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. Easy as an arm chair theory, impossible in practice without a complete rewrite of git from scratch. You are also disregarding the immutability of the data and the append-only property of stored datasets in ledger DB's: the entire temporal history of changes to a document (or a table) must be available in a ledger database. Changes are linked by virtue a Merkle tree, and the content of each node (i.e. revision) can be cryptographically proven to be untampered with. QLDB documentation provides a visualisation of the cryptographic verification process and of a sequence of steps: https://docs.aws.amazon.com/qldb/latest/developerguide/verification.html https://docs.aws.amazon.com/qldb/latest/developerguide/verif... Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. So no, Git it is not easy to build a ledger database out of git if there are strict compliance requirements as I can pull out a revision M out of N revisions of my documents stored in a ledger database, run the revision N through the proof interface and use it in a court hearing as evidence or turn it over to external auditors. And no external auditing body will ever certify a git based solution.
- jillesvangurp 4y ago
  > Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. Read up on git internals, it's a very elegant and simple design and you seem to assume a few things about it that are flat out wrong. A git repository is in fact a Merkle tree. Every commit is chained to the previous commit via a hash that includes the commit content and the hash of the previous commit. So, git history is immutable. You can't modify commits without breaking the chain of hashes. It's by definition append only. You can of course modify your local copy of a git repository and rewrite history (i.e. change all the hashes). But that makes it incompatible with upstream history. People tend to use this to clean up their local change history before they send it upstream. With the exception of force push (i.e. just overwrite the remote repository), there is no way to merge a rewritten history. In order to merge changes, there MUST be a shared commit with the same history. It's not optional.