5 ms·

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.

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.
  - inkyoto 4y ago
    > 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. I am well acquainted with git internals and object types, which include blobs, trees, commits, and tags. But I do acknowledge that I was wrong about git not hashing the object's contents – it does. > 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. Commits in git are grouped into commit trees that form a single atomic commit, and git allow manipulations of the commit trees, which is fundamentally unacceptable for an immutable, verifiable ledger. That is why I am asserting that git is not an acceptable technology for a ledger. > 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. I have personally squashed commits in my local project copy and force pushed such a squashed commit into a upstream repository thereby completely decimating the commit history in the upstream repository. Previous commit history was completely gone every single time. It is an occasionally useful feature (i.e. fixing mistakes of young developers), but the commit history rewrite is absolutely unacceptable in the compliance world. Just the fact that there is direct, unabridged write access to the history or to the storage where the history is recorded makes such a solution untenable as a ledger database. I do concede that there are some conceptual similarities between git and ledger databases at the architectural level; I do, however, vociferously dispute the suitability of git as a foundation for building a ledger database without a substantial rewrite of the git foundation.

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.
- inkyoto 4y ago
  > 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. I am well acquainted with git internals and object types, which include blobs, trees, commits, and tags. But I do acknowledge that I was wrong about git not hashing the object's contents – it does. > 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. Commits in git are grouped into commit trees that form a single atomic commit, and git allow manipulations of the commit trees, which is fundamentally unacceptable for an immutable, verifiable ledger. That is why I am asserting that git is not an acceptable technology for a ledger. > 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. I have personally squashed commits in my local project copy and force pushed such a squashed commit into a upstream repository thereby completely decimating the commit history in the upstream repository. Previous commit history was completely gone every single time. It is an occasionally useful feature (i.e. fixing mistakes of young developers), but the commit history rewrite is absolutely unacceptable in the compliance world. Just the fact that there is direct, unabridged write access to the history or to the storage where the history is recorded makes such a solution untenable as a ledger database. I do concede that there are some conceptual similarities between git and ledger databases at the architectural level; I do, however, vociferously dispute the suitability of git as a foundation for building a ledger database without a substantial rewrite of the git foundation.