2

A couple of us on the web3.js gitter forum were discussing the need for a 3rd party check on logs that could potentially be years old.

From what we can tell, some nodes are not keeping the old logs around for filtering because they take up valuable space and are not necessary for running the current blocks.

However, those logs are valuable for off-chain third party verification. (e.g. lawyers), years later.

One can configure ones own node(s) to keep all the old logs around, but that does not constitute a third party verification. Remember this is off-chain and understanding vs. traditions are odd sounding to the technical world.

Are there blockchain browsers that keep all the old logs around? What are some other possible solutions? (Or am I missing something obvious?)

Improve this question
5
  • When you say logs do you mean transaction events or the output from the ethereum client? If you mean transaction events they are part of the blockchain you should be able to verify if they belong to a block. – Ismael Oct 10 '17 at 4:54
  • The ethereum yellow paper uses the term logs, and Solidity uses the term events, but they are the same thing. And my general understanding (which is part of the question is the nodes do not keep the bloom filters up to date. Kind of hard to audit the logs if you can't find anything... – Paul S Oct 11 '17 at 14:13
  • 1
    If you have a 'full' node you will have all the information required. With a 'fast' node you can't make some queries because the processed information from old blocks is not available, but you have the raw blocks, for an audit it should be enough. – Ismael Oct 11 '17 at 16:43
  • add a source and you have an answer, I think. though I'm curious if raw blocks means "just a blob", or "structured data". (e.g. is byte 37 part of a log, input data, or state?) – Paul S Oct 11 '17 at 23:07
  • Here geth developer Péter Szilágyi says how to convert from fast node to full node without downloading the blockchain again ethereum.stackexchange.com/a/3506. I remember a better answer by him but I can't find it. – Ismael Oct 12 '17 at 0:17
2

It's useful to remember that in Ethereum, the single version of the truth is the blockchain. If you have the blockchain, you always have enough information to answer any question about anything that has happened on it. If you've got a copy of the blockchain, you can validate every block, transaction-by-transaction, starting from the genesis block. Indeed this is what a full node will do when first starting up.

When a node is validating the blockchain, and encounters a transaction that emits a log message, it has a few options:

  • Since log messages don't have any impact on future transactions, the node has no inherent need to store them in a readily queriable form (miners will likely do this, as they are not interested in logs and have no reason to waste the space).
  • The node can store them in some sort of indexed database (possibly only including recent logs, depending on whether this is a "full" node of a "fast" node).
  • Since the log bloom filters are stored in the blockchain, the node could discard logs, but store enough snapshots of the state trie that if a log is emitted in a particular block (which can be determined quickly from the raw blockchain data), it can replay to a given point reasonably quickly.
  • The node could write them all to a text file, or print them out, or anything it wants.

The key point is that the log messages emitted are deterministic, and depend only on the transactions that are in the blockchain. If you've got the blockchain, you can reprocess it any of the ways detailed above (including rebuilding a full node), and get the information about the logs out.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.