5 ms·

the entire state of the database gets captured by a hash value. By having light-weight clients (or auditors) keeping track of it is how tampering is detected in

the entire state of the database gets captured by a hash value. By having light-weight clients (or auditors) keeping track of it is how tampering is detected in despite of where the database server is running

capableweb 5y ago
I see. It's a blockchain without calling it a blockchain, so people who hate blockchain can use it without having to realize they use a blockchain.
- f38zf5vdt 5y ago
  And with git being the most superior blockchain of them all.
  - ric2b 5y ago
    Except it has no way to achieve consensus automatically. That's left as an exercise to the reader.
- jacquesm 5y ago
  Blockchain is just a special case of Merkle trees, there isn't anything original about them other than that Bitcoin served as a marketing engine for the term blockchain because some people made a ton of money with it. https://en.wikipedia.org/wiki/Merkle_tree https://en.wikipedia.org/wiki/Merkle_tree
  - deleted 5y ago
    [deleted]
  - decodebytes 5y ago
    Rekor is just that. It's a merkle tree implementation (with extras such as timestamping) https://github.com/sigstore/rekor https://github.com/sigstore/rekor
  - joshuak 5y ago
    No block chains are different than Merkle trees entirely. Block chains include previous hashes in each block, whereas Merkle trees, as the name implies are trees of hashes. In Merkle trees blocks do not include the previous block's hash.
    - aboodman 5y ago
      In git each "block" includes the previous "block"(s)' hash. Is it a blockchain or a hash tree? I would say that in practice what differentiates a blockchain from other applications of hash trees is a mechanism for consensus, not whether the blocks being formed into a trees conceptually represent time or not.
      - joshuak 5y ago
        Git is a block chain. Block chains require a previous block's hash to denote sequence. The hash for any block of data can be appended to Merkle tree, even duplicate blocks. In a block chain it is easy to find history because the link to the history is included. Merkle trees require n-1 additional hashes.
        aboodman 5y ago
        Disagree. There are not formal definitions for these terms, but I don't think your definition here is what most people would think of as a blockchain.
        joshuak 5y ago
        Looking at the wikipedia article I can see where one might be confused. A blockchain is a growing list of records, called blocks, that are linked together using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a Merkle tree). The Merkle tree referenced here is with respect to the organization of the transaction data contained within a block, not the blockchain itself. Merkle trees are used in various ways within cryptography in general and cryptocurrencies specifically, but blockchains and Merkle trees are distinct data structures with different uses. The colloquial use of "blockchain" has perhaps made the word somewhat ambiguous in some contexts but not in the context of cryptographic data structures, and Merkle trees are in fact formally defined.
  - dmacvicar 5y ago
    You can visualize how immudb Merkle tree grows as you insert data on https://play.codenotary.com https://play.codenotary.com
  - ric2b 5y ago
    > there isn't anything original about them Cool, so let's say we're using this to track financial transactions. Server A has an Immudb at some state x and server B has an Immudb at some state y. Which one is correct, how do I decide?
- ForHackernews 5y ago
  It's only the actually-useful bits of a "blockchain" without the planet-cooking proof-of-waste consensus algorithm brute-forcing sha256 over and over again.
  - ric2b 5y ago
    And also without the useful "automatically achieve consensus between untrusted parties" bit.
deleted 5y ago
[deleted]
exfalso 5y ago
This is insufficient. The strongest guarantee you can get without consensus is that the state of the DB you see on the client is/was a correct state at some point, it doesn't provide freshness/rollback attack prevention, aka that the state you see is in fact the latest one. Keeping track of the "HEAD" hash on the clients is what consensus protocols achieve. You can also achieve it with trusted counters like the one SGX provides (depends on Intel ME so not exactly recommended, also most probably switched off in cloud environments). Alternative is an implementation of something like https://dl.acm.org/doi/10.5555/3241189.3241289 https://dl.acm.org/doi/10.5555/3241189.3241289. You can of course say that it's the clients' responsibility to do this, but in practice they won't and they'll implicitly trust the server state. Having said this, the project does look promising, we may end up using it in a confidential compute setting where clients can verify the server code running, and we'll add rollback protection on top
- toolslive 5y ago
  > aka that the state you see is in fact the latest one. This is an impossible guarantee. Suppose the state that is sent to you from the server needs some time to get to you. meanwhile the state on the server could have changed. You don't even need a remote server to have this issue. Your thread (where you see the latest state) is put to sleep for a while (sheduler, os, ...) It wakes up. Is the state it observes still the latest? That's impossible to know. The only thing you can do is to refuse future updates if the state they were built upon is not the current state of the database.
  - exfalso 5y ago
    That's what I meant. If you have many transactions building on a state hash X racing to be committed, only one of them will succeed. With crypto protocols in general "guarantees" are always prefixed with "if the protocol completed successfully, then ...". For example authenticated DH + e2e encryption guarantees that you will send data to the intended participant only. But an attacker can still disrupt the network packets, so the true guarantee is "if the protocol completed successfully, then you have sent the data to the intended participant only". Same thing here, you cannot of course guarantee the "latest state", if we want to go into the extreme, one could even argue that actually time doesn't work like that because of relativity/speed of light limitations:D. What you can guarantee is that if your commit protocol succeeded, then it updated the latest state at the time of consensus/monotonic counter update.

capableweb 5y ago

I see. It's a blockchain without calling it a blockchain, so people who hate blockchain can use it without having to realize they use a blockchain.

f38zf5vdt 5y ago
And with git being the most superior blockchain of them all.
- ric2b 5y ago
  Except it has no way to achieve consensus automatically. That's left as an exercise to the reader.
jacquesm 5y ago
Blockchain is just a special case of Merkle trees, there isn't anything original about them other than that Bitcoin served as a marketing engine for the term blockchain because some people made a ton of money with it. https://en.wikipedia.org/wiki/Merkle_tree https://en.wikipedia.org/wiki/Merkle_tree
- deleted 5y ago
  [deleted]
- decodebytes 5y ago
  Rekor is just that. It's a merkle tree implementation (with extras such as timestamping) https://github.com/sigstore/rekor https://github.com/sigstore/rekor
- joshuak 5y ago
  No block chains are different than Merkle trees entirely. Block chains include previous hashes in each block, whereas Merkle trees, as the name implies are trees of hashes. In Merkle trees blocks do not include the previous block's hash.
  - aboodman 5y ago
    In git each "block" includes the previous "block"(s)' hash. Is it a blockchain or a hash tree? I would say that in practice what differentiates a blockchain from other applications of hash trees is a mechanism for consensus, not whether the blocks being formed into a trees conceptually represent time or not.
    - joshuak 5y ago
      Git is a block chain. Block chains require a previous block's hash to denote sequence. The hash for any block of data can be appended to Merkle tree, even duplicate blocks. In a block chain it is easy to find history because the link to the history is included. Merkle trees require n-1 additional hashes.
      - aboodman 5y ago
        Disagree. There are not formal definitions for these terms, but I don't think your definition here is what most people would think of as a blockchain.
        joshuak 5y ago
        Looking at the wikipedia article I can see where one might be confused. A blockchain is a growing list of records, called blocks, that are linked together using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a Merkle tree). The Merkle tree referenced here is with respect to the organization of the transaction data contained within a block, not the blockchain itself. Merkle trees are used in various ways within cryptography in general and cryptocurrencies specifically, but blockchains and Merkle trees are distinct data structures with different uses. The colloquial use of "blockchain" has perhaps made the word somewhat ambiguous in some contexts but not in the context of cryptographic data structures, and Merkle trees are in fact formally defined.
- dmacvicar 5y ago
  You can visualize how immudb Merkle tree grows as you insert data on https://play.codenotary.com https://play.codenotary.com
- ric2b 5y ago
  > there isn't anything original about them Cool, so let's say we're using this to track financial transactions. Server A has an Immudb at some state x and server B has an Immudb at some state y. Which one is correct, how do I decide?
ForHackernews 5y ago
It's only the actually-useful bits of a "blockchain" without the planet-cooking proof-of-waste consensus algorithm brute-forcing sha256 over and over again.
- ric2b 5y ago
  And also without the useful "automatically achieve consensus between untrusted parties" bit.

deleted 5y ago

[deleted]

exfalso 5y ago

This is insufficient. The strongest guarantee you can get without consensus is that the state of the DB you see on the client is/was a correct state at some point, it doesn't provide freshness/rollback attack prevention, aka that the state you see is in fact the latest one. Keeping track of the "HEAD" hash on the clients is what consensus protocols achieve. You can also achieve it with trusted counters like the one SGX provides (depends on Intel ME so not exactly recommended, also most probably switched off in cloud environments). Alternative is an implementation of something like https://dl.acm.org/doi/10.5555/3241189.3241289 https://dl.acm.org/doi/10.5555/3241189.3241289. You can of course say that it's the clients' responsibility to do this, but in practice they won't and they'll implicitly trust the server state. Having said this, the project does look promising, we may end up using it in a confidential compute setting where clients can verify the server code running, and we'll add rollback protection on top

toolslive 5y ago
> aka that the state you see is in fact the latest one. This is an impossible guarantee. Suppose the state that is sent to you from the server needs some time to get to you. meanwhile the state on the server could have changed. You don't even need a remote server to have this issue. Your thread (where you see the latest state) is put to sleep for a while (sheduler, os, ...) It wakes up. Is the state it observes still the latest? That's impossible to know. The only thing you can do is to refuse future updates if the state they were built upon is not the current state of the database.
- exfalso 5y ago
  That's what I meant. If you have many transactions building on a state hash X racing to be committed, only one of them will succeed. With crypto protocols in general "guarantees" are always prefixed with "if the protocol completed successfully, then ...". For example authenticated DH + e2e encryption guarantees that you will send data to the intended participant only. But an attacker can still disrupt the network packets, so the true guarantee is "if the protocol completed successfully, then you have sent the data to the intended participant only". Same thing here, you cannot of course guarantee the "latest state", if we want to go into the extreme, one could even argue that actually time doesn't work like that because of relativity/speed of light limitations:D. What you can guarantee is that if your commit protocol succeeded, then it updated the latest state at the time of consensus/monotonic counter update.