Append-Only Log Verification Without Verifier Hash Storage
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing ledger verification systems are vulnerable to tampering, and existing proof of storage techniques require additional storage and specialized encoding, or rely on verifiers maintaining hash values, which is inefficient and resource-intensive.
Innovation Solution
A tamper-resistant log system where a storage provider maintains an append-only log with entries containing data, signatures, and hash values based on preceding entries, allowing on-demand verification using public keys, private keys, or zero-knowledge proofs, without requiring verifiers to maintain hash values.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If existing proof of storage techniques are used to verify ledger integrity, then verification capability is provided, but additional storage overhead and specialized encoding requirements are introduced
Solution Approach 1:
The patent extracts the verification mechanism from the stored data by using cryptographic hash functions. Instead of storing additional verification data, the system computes hash values of the log entries and stores only these hash values in the log itself. Each log entry contains a hash of the previous entry, creating a chain that enables verification without requiring external storage of verification data.
Solution Approach 2:
The hash value in each log entry serves multiple functions: it acts as an integrity check for the current entry, a link to the previous entry in the chain, and a basis for verifying the entire log history. This multi-functional use of hash values eliminates the need for separate verification data structures.
2Measurement precision
If verifiers maintain hash values for verification purposes, then verification accuracy is improved, but resource consumption and complexity increase
Solution Approach 1:
The log structure is designed to be self-verifying. Each log entry contains all the information needed for verification (the hash of the previous entry and the current entry's data). A verifier can independently compute the hash of the current entry and compare it with the stored hash in the next entry, without needing to maintain external hash values or complex verification state.
Solution Approach 2:
The hash values are pre-computed and embedded in the log entries during log creation. This preliminary computation eliminates the need for verifiers to perform complex real-time hash computations or maintain hash value caches, reducing verifier complexity to simple hash computation and comparison.
3Ease of operation
If traditional ledger verification methods are used, then basic verification is provided, but vulnerability to tampering persists
Solution Approach 1:
The system pre-computes and embeds cryptographic hash values in each log entry before the log is finalized. This preliminary cryptographic binding creates a tamper-resistant chain where any modification to a previous entry would change its hash value, which would then not match the hash stored in the subsequent entry, making tampering immediately detectable.
Solution Approach 2:
The patent replaces mechanical or administrative verification methods with cryptographic verification. Instead of relying on physical security or procedural controls to prevent tampering, the system uses cryptographic hash functions to create a mathematically guaranteed tamper-evident log structure that is resistant to tampering by design.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
Verification of a tamper-resistant log is disclosed herein. A storage provider maintains an append-only log storing a first log entry written by a first writer, the first log entry comprising first log data, a first signature and a first hash value. A verifier requests, from the storage provider, verification of the first log entry. The verifier obtains, from the storage provider, the first log entry and at least a portion of a second log entry preceding the first log entry to enable verification of the first log entry, wherein the second log entry comprises second log data, a second signature and a second hash value. The first log entry is verified based, at least in part, on the portion of the second log entry.