{
  "id": 9072482,
  "title": "Verifiable Record Integrity Without a Blockchain",
  "url": "https://urgent.news/2026/09/22/verifiable-record-integrity-without-a-blockchain",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-22T03:15:08.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/viktorkhudiaiev/verifiable-record-integrity-without-a-blockchain-2pnd"
  },
  "original_language": "en",
  "account": "In digital transactions, maintaining verifiable record integrity is crucial, even without the use of blockchain technology. The primary concern revolves around who can alter the database and what effects those changes would have. A database can remain functional, answering queries accurately while still harboring fraudulent data. An attacker possessing adequate database privileges could manipulate recipient details, insert fictitious transfers, repeat past operations, or delete inconvenient records.\n\nThe crux of the issue is whether we can restrict administrative access to a transaction database enough to prevent unauthorized financial actions, all while preserving evidence of its content modifications. This article outlines a local reference implementation that merges conventional cryptographic methods with a safeguarded execution environment. It employs standard PostgreSQL, three Java services, and simulated transactions. Importantly, it does not introduce novel cryptographic elements or claim to supplant all ledger databases. Instead, its main contribution lies in the integration of various components: exact operation content authentication, independent evidence retention before publication, execution of only checked operations, and recovery from retries without duplicating financial impacts.\n\nUnder this explicitly centralized trust model, the architecture does not necessitate distributed consensus. The attacker in this scenario retains control over the primary transaction database, encompassing administrative rights. They have the capability to insert, modify, delete, replay, reorder, or restore database contents, and even disable triggers. The application, key service, processor, Audit/Protected database, and embedded broker, alongside service credentials and the underlying host, remain trusted entities. Despite these conditions, the attacker's control over the primary database alone is insufficient to execute forged, altered, or settled operations.\n\nThe outlined tests assess this limited claim but are not proofs against all conceivable attacks. This distinction informs the architectural design: if the attacker also controls the authoritative balances, they can directly alter them. If they control the service responsible for authenticating new instructions, they can request the authentication of fraudulent instructions. However, a Message Authentication Code (MAC) column cannot remedy either of these boundaries. The application's responsibility remains in validating identities and enforcing business authorization. The integrity module authenticates service requests and safeguards operation content; it does not introduce additional identity providers or ensure database security or availability.\n\nThe model employs two PostgreSQL instances, with the primary database remaining under the attacker's control. The Audit/Protected database serves as the repository for evidence and notification tables. It performs independent issuance receipts, creates ordered audit evidence, and maintains a durable incident-notification outbox. These components operate outside the primary administrator's purview. The accounting tables contain balances, account holds, paired postings, execution journal, durable jobs, and outcome outboxes. These trusted financial effects reside within the same protected database. The application seeks authentication from the key service and submits the resulting operation to the primary database. The processor verifies candidates and facilitates settlement. Separate service credentials restrict access to issuance, verification, key administration, and checkpoint signing. The application does not receive key bytes or settlement SQL access; the processor cannot issue new operation MACs. Despite running on a single trusted Windows host, different database instances and credentials illustrate the intended access boundaries. Yet, in a production environment, independent identities, custody, and operational ownership are essential—not just extra schemas under the same administrator. Authenticating byte content, rather than informal record descriptions, is crucial. The implementation utilizes HMAC-SHA256, a widely established method, as described in RFC 2104. The key challenge lies in defining the exact content to be authenticated. Employing byte-exact type-length-value encoding ensures that each field has a one-byte numeric identifier, a one-byte type, an unsigned four-byte big-endian byte length, and its value. The fields follow a fixed sequence: domain, schemaVersion, keyId, id, ledgerId, and others.",
  "summary": "Authenticated execution and independently retained evidence for a PostgreSQL transaction workflow Viktor Khudiaiev · Publication updated September 20, 2026 Disclaimer: The views expressed in this article are my own and do not reflect those of my employer. This article describes independent personal work and is unrelated to my work for my employer. Implementation reviewed: source snapshot e2e35de…",
  "key_points": [
    "Database can remain functional with fraudulent data",
    "Attackers with privileges can manipulate records",
    "Architecture uses centralized trust model without consensus"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}