8 ms·

I don't quite understand how something you run yourself on your own hardware can be tamper-proof (digitally, not physically). If you're running the software you

• jeroiraz 5y ago
  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.
              • 5y ago
    • 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.
• rcoder 5y ago
  You can build a Merkle tree from any data that is append-only; Git does this, as do ZFS and Dat/Hypercore. That lets you make strong assertions about data integrity, even without blocking local writes. Now add a mirror: git upstream, FS snapshot, immudb replica, etc…or even just an outside log of the merkle proofs themselves. Then, if your database ever fails a check against that proof, you know the data has been modified, not just appended to. To use a familiar Git workflow example: you can do whatever local writes you want, but if you disallow force pushes no one can erase history on the upstream repo. Put another way: if you have immutable backups you don’t need a blockchain to ensure data integrity. OTOH, if you can’t trust your own infrastructure even as far as a secure remote backup you have other problems that a blockchain won’t solve either.
  • fastball 5y ago
    Again though, the entire point of blockchain tech is that it's decentralized. In the git analogy, someone is "disallowing force pushes", but the person that is disallowing can modify the database.
    • swsieber 5y ago
      You can use git in a secure decentralized way - you have people sign commits.
  • dmacvicar 5y ago
    by the way, you can play with immudb Merkle tree visually on https://play.codenotary.com https://play.codenotary.com
• rhacker 5y ago
  you can do something quite simple like posting a tweet or inserting something into a public chain, like Etherium. Then follow that back to the private immudb hash.
• foepys 5y ago
  Blockchains like Bitcoin are actually not tamper-proof. They can be attacked by 51% attacks where you can even rewrite history if you have enough hashpower. The protocol is explicitly designed to always follow the longest chain thus the only defense is to hash faster than the attackers. This might vary for other blockchains but the biggest and most mentioned is particularly unsafe in that regard.
  • kdragon 5y ago
    You can't rewrite the history of blocks that have already been distributed. You may fool SPV nodes but any node with a copy of the blockchain (even if pruned) will reject your version.
    • deleted 5y ago
      [deleted]
    • foepys 5y ago
      This is false. Please read the white paper. It clearly states in section 4: > The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. If the majority of the hashpower (not nodes!) is dishonest, you can rewrite history. It's the reason why the current difficulty is part of a block. This has been done numerous times in the past for small but highly traded altcoins.
  • deleted 5y ago
    [deleted]
  • PhilippGille 5y ago
    There are wo things you skip over: 1. You can't rewrite everything. Given enough hash power to create a longer chain, you can create a block that a) removes any transactions from a block in the original chain and b) contains new valid transactions (must be signed by you so you must be the owner of the Bitcoins used in the tx), allowing you to double spend your coins, but you can't change other people's transactions. 2. With each new block changing a past one becomes harder, while you make it sound as if you could arbitrarily rewrite history. Merchants usually wait several blocks before accepting your on-chain payment. Exchanges wait 6 blocks as that's seen as infeasible to change a block that's buried under 5 other blocks for non-nation state actors. TL;DR: 1) Other people's transactions can at most be removed but not be changed and 2) data on the Bitcoin blockchain is tamper proof after x blocks.
• theamk 5y ago
  You can still have the extra verifier nodes, but those don't have to be on the critical read/write path. Presumably you can create a config where have your "main" beefy server where all the activity is -- which is backed up, redundant, etc... And a bunch of "client" servers, which just pull and verify the data all the time. And the client servers notify if there are any errors using some out-of-band channel, probably using the same system you use for general server health monitoring. So you are getting same security guarantees as "private blockchain", but with drastically higher performance, and only needing one beefy server. And the downside is that you won't auto-stop all operations on tampering, you'll only get an alert for it.
• akiselev 5y ago
  > immudb doesn't actually seem to replace the use case when you need something actually tamper-proof. I think that's an unrealistic requirement. There's tamper-evident and tamper-resistant but AFAIK nothing is tamper proof. Best you can do is an HSM with a tamper resistant HMAC with keys and a running checksum in unrecoverable ROM coupled to the packaging.
  • capableweb 5y ago
    > nothing is tamper proof I beg the differ. If I place a signed message in the Bitcoin chain, can you then modify that message? If you can prove that you can somehow modify the message, I'll give you $1,000,000 USD tomorrow.
    • k_ 5y ago
      Not after you post it, but by infecting your device before you make that message, and tampering when you place it in the Bitcoin chain
      • capableweb 5y ago
        So you agree, once it's on the blockchain, it's tamper-proof?
    • akiselev 5y ago
      That's "tamper proof" in the colloquial sense. As a term of art, it means something very specific. For example, see FIPS 140-2/3 [1] It makes no sense to say that the blockchain is tamper proof because the blockchain is just information. Tamper "proofness"/resistance is first a property of the devices storing the information - once you get into custody chains, provenance documents, etc. that's when a system becomes tamper resistant. At best the blockchain as a system is "tamper evident" in the colloquial sense because the network of all the other nodes decides which bits of information form the "real" blockchain. However, without verifying the (physical) identity and data integrity of the devices that run (at least?) 50%+1 of the nodes, you have no idea whether the system has been tampered with. [1] https://en.wikipedia.org/wiki/FIPS_140 https://en.wikipedia.org/wiki/FIPS_140