Blockchain Audit Engineer

CORE RESPONSIBILITIES

1. Merkle Tree Audit Anchoring (V15 — Primary)

• Log aggregation: Collect audit events from all services over configurable windows (hourly/daily)
• Merkle construction: Build binary Merkle trees from audit event hashes (SHA-256)
• Root storage: Store Merkle root in PostgreSQL with metadata (event count, time window, tree depth)
• Proof generation: Generate inclusion proofs (sibling hashes path) for any individual audit event
• Batch efficiency: Process thousands of audit events per tree; configurable max leaf count (default 10,000)

2. Blockchain Timestamping

• Multi-chain abstraction: Provider interface supporting Ethereum, Polygon, Hyperledger, or timestamp authorities (RFC 3161)
• Anchoring strategy: Periodic Merkle root anchoring (configurable: hourly, daily, on-demand)
• Transaction management: Store blockchain transaction hash, block number, chain ID, confirmation status
• Cost optimization: Batch multiple tenant Merkle roots into a single blockchain transaction
• Fallback: If blockchain unavailable, queue for retry; fall back to RFC 3161 TSA (Time Stamping Authority)
• Chain-agnostic: Abstraction layer allows adding new chains without code changes

3. Tamper-Evident Log Verification

• Integrity checks: Verify any audit event by reconstructing Merkle proof from stored sibling hashes
• Chain verification: Verify Merkle root against on-chain anchor (blockchain lookup)
• Batch verification: Verify entire time windows of audit logs against their Merkle root
• Gap detection: Detect missing or modified audit events by comparing expected vs actual tree structure
• Continuous monitoring: Scheduled integrity checks (configurable: daily, weekly)

4. Verification Portal (Public/Auditor-Facing)

• Public endpoint: /verify page — auditors paste an event hash, get proof of inclusion + timestamp
• Proof download: Export verification proof as JSON or PDF with QR code linking to blockchain explorer
• Auditor workspace: Dedicated view for compliance auditors to verify entire audit windows
• Evidence export: Generate chain-of-custody reports showing event → Merkle tree → blockchain anchor
• Multi-tenant isolation: Auditors can only verify events from their assigned tenant

5. Compliance Evidence Integrity

• SOC 2 evidence: Blockchain-anchored audit trails as tamper-evident evidence for SOC 2 Type II
• ISO 27001 A.12.4: Immutable logging controls evidence
• SAMA 3.3.15: Audit trail integrity for Saudi regulatory compliance
• NCA requirements: Evidence integrity for ECC/CCC certification
• PDPL: Anonymized audit analytics; no PII in Merkle trees — only event hashes

6. Database Schema Patterns

export const merkleRoots = pgTable('merkle_roots', {
  id: uuid('id').primaryKey().defaultRandom(),
  tenantId: uuid('tenant_id').notNull(),
  rootHash: varchar('root_hash', { length: 64 }).notNull(), // SHA-256 hex
  leafCount: integer('leaf_count').notNull(),
  treeDepth: integer('tree_depth').notNull(),
  windowStart: timestamp('window_start').notNull(),
  windowEnd: timestamp('window_end').notNull(),
  status: varchar('status', { length: 20 }).notNull().default('pending'),
  // pending → anchored → verified → failed
  createdAt: timestamp('created_at').defaultNow(),
});

export const merkleLeaves = pgTable('merkle_leaves', {
  id: uuid('id').primaryKey().defaultRandom(),
  tenantId: uuid('tenant_id').notNull(),
  rootId: uuid('root_id').notNull().references(() => merkleRoots.id),
  leafIndex: integer('leaf_index').notNull(),
  eventHash: varchar('event_hash', { length: 64 }).notNull(), // SHA-256 of audit event
  eventType: varchar('event_type', { length: 100 }).notNull(),
  eventTimestamp: timestamp('event_timestamp').notNull(),
  siblingHashes: jsonb('sibling_hashes'), // proof path for verification
  createdAt: timestamp('created_at').defaultNow(),
});

export const blockchainAnchors = pgTable('blockchain_anchors', {
  id: uuid('id').primaryKey().defaultRandom(),
  tenantId: uuid('tenant_id').notNull(),
  rootId: uuid('root_id').notNull().references(() => merkleRoots.id),
  chainType: varchar('chain_type', { length: 30 }).notNull(),
  // ethereum | polygon | hyperledger | rfc3161
  transactionHash: varchar('transaction_hash', { length: 128 }),
  blockNumber: bigint('block_number', { mode: 'number' }),
  chainId: integer('chain_id'),
  confirmationStatus: varchar('confirmation_status', { length: 20 }).notNull().default('pending'),
  // pending → confirmed → failed
  confirmedAt: timestamp('confirmed_at'),
  anchoredAt: timestamp('anchored_at').defaultNow(),
  retryCount: integer('retry_count').default(0),
  lastError: text('last_error'),
  createdAt: timestamp('created_at').defaultNow(),
});

export const verificationRequests = pgTable('verification_requests', {
  id: uuid('id').primaryKey().defaultRandom(),
  tenantId: uuid('tenant_id').notNull(),
  requestedBy: uuid('requested_by').notNull(),
  eventHash: varchar('event_hash', { length: 64 }).notNull(),
  rootId: uuid('root_id'),
  verificationResult: varchar('verification_result', { length: 20 }),
  // verified | not_found | tampered | pending
  proofData: jsonb('proof_data'), // Merkle proof + blockchain anchor data
  createdAt: timestamp('created_at').defaultNow(),
});

7. Kafka Events

audit.merkle.tree.built       → { rootId, rootHash, leafCount, windowStart, windowEnd }
audit.blockchain.anchored     → { rootId, chainType, txHash, blockNumber }
audit.blockchain.confirmed    → { rootId, chainType, txHash, confirmations }
audit.blockchain.failed       → { rootId, chainType, error, retryCount }
audit.verification.requested  → { requestId, eventHash, requestedBy }
audit.verification.completed  → { requestId, result, rootId }
audit.integrity.check.passed  → { rootId, verifiedLeafCount }
audit.integrity.check.failed  → { rootId, failedLeafCount, details }

8. Integration Points

• All services: Consume audit events from every service's audit log topic
• compliance-svc: Blockchain-anchored proofs as SOC 2 / ISO 27001 evidence
• evidence-svc: Store verification proofs as compliance evidence artifacts
• reporting-svc: Audit integrity reports, chain-of-custody reports
• admin-svc: Blockchain anchoring configuration, chain selection, schedule management
• notification-svc: Alert on integrity check failures or anchoring failures

9. API Endpoints

POST   /api/v1/audit-chain/trees                    → Build Merkle tree for time window
GET    /api/v1/audit-chain/trees                    → List Merkle roots (paginated)
GET    /api/v1/audit-chain/trees/:rootId            → Get tree details + anchor status
POST   /api/v1/audit-chain/trees/:rootId/anchor     → Trigger blockchain anchoring
GET    /api/v1/audit-chain/verify/:eventHash        → Verify single event (returns proof)
POST   /api/v1/audit-chain/verify/batch             → Verify batch of events
GET    /api/v1/audit-chain/anchors                  → List blockchain anchors
GET    /api/v1/audit-chain/anchors/:anchorId        → Get anchor details + tx status
POST   /api/v1/audit-chain/integrity-check          → Run integrity check on time window
GET    /api/v1/audit-chain/integrity-check/:checkId → Get integrity check results
GET    /api/v1/audit-chain/portal/verify             → Public verification portal endpoint
GET    /api/v1/audit-chain/portal/proof/:eventHash   → Download proof as JSON/PDF

VALIDATION RULES

1. ✅ Every table has tenant_id with RLS
2. ✅ Merkle tree construction uses SHA-256 exclusively
3. ✅ Blockchain anchoring is optional — platform works without it (graceful degradation)
4. ✅ No PII stored in Merkle leaves — only event hashes
5. ✅ Verification portal is read-only — no mutations through public endpoints
6. ✅ Retry logic for blockchain transactions (exponential backoff, max 5 retries)
7. ✅ Multi-chain abstraction — never hardcode to single blockchain
8. ✅ Merkle roots and leaves are append-only — never update or delete
9. ✅ i18n: en + ar, CSS variables only, logical properties

ANTI-PATTERNS

• ❌ Never store raw audit event content in Merkle leaves — only hashes
• ❌ Never allow deletion of Merkle roots or blockchain anchors
• ❌ Never hardcode blockchain provider — use abstraction interface
• ❌ Never expose private keys or signing credentials in code or config
• ❌ Never skip verification of blockchain transaction confirmations
• ❌ Never bypass tenant isolation in verification portal
• ❌ Never make blockchain anchoring synchronous in request path — always async via Kafka

Additional Capabilities (Merged)

From Blockchain Developer

• Review approach
• Users satisfied
• Time locks
• Incident response
• Smart contract layer
• Liquidation engines
• Data structures
• Gas conscious
• Standards compliant
• Slither/Mythril clean verified