Expanding Guardian with a Multi-Dimensional Trustchain and Post-Issuance Verification

[mattsmithies]

Overview

This proposal suggests a shift from Guardian’s current single-thread trustchain approach to a multi-dimensional trustchain model with post-issuance verification capabilities. This approach is fundamentally different from Guardian’s existing architecture, but, given potential challenges, it’s worth careful consideration.

To illustrate the advantages, here’s a thought experiment contrasting a single-thread trustchain with a multi-dimensional trustchain, especially as it relates to GDPR compliance, role flexibility, and the evolving responsibilities of different actors.

Shifting Roles of Data Controller and Processor

Under GDPR, the registry that initiates the process will begin as the data controller. As data moves through different validation phases, however, responsibility could shift to a VVB or verifier, making the initial registry a data processor. This means the VVB would assume greater accountability for data integrity and compliance—a significant change unless the registry maintains a proxy role, controlling the entire flow (legal clarification needed for last point).

A multi-dimensional trustchain would better support these role transitions, enabling data controllers and processors to shift dynamically, reducing regulatory risk and allowing the system to adapt to various compliance and operational needs.

Thought Experiment: Single-Thread vs. Multi-Dimensional Trustchain

Consider a scenario where a VVB involved in the issuance of a credit is no longer active, whether due to business closure, lost accreditation, or changing standards. What implications would this have for data, token provenance, and regulatory requirements?

Basic Trustchain Scenario

• In the current basic trustchain approach, each credit is tied to a single verification path, creating an immutable, linear record. If the original VVB goes out of business, there is no clear mechanism for re-validating the data. This rigid structure creates a weak link in the chain, as regulatory compliance and market trust are at risk if the initial verifier can’t be replaced.
• Because the VVB was the data controller, GDPR compliance becomes complicated if there’s no mechanism for role re-assignment. This also makes it challenging to ensure the data remains valid under changing legal or industry standards.

Multi-Dimensional Trustchain Scenario

• In a multi-dimensional trustchain, each data block is part of a flexible, layered structure, allowing multiple VVBs to validate data and new actors to add post-issuance attestations. If the original VVB is no longer available, the registry could approve new VVBs to step in, updating terms and validations without duplicating data.
• By allowing VVB roles to be reassigned seamlessly, this approach ensures that data integrity and regulatory compliance are maintained. Credits retain market trust as new validators or controllers ensure ongoing verification even as standards change.

Benefits of a Multi-Dimensional Trustchain for Guardian

This flexible model would allow Guardian to handle multi-actor verification efficiently, adapt to regulatory standards, and provide post-issuance validations. Key benefits include:

• Flexibility in Role Transitions: Supports dynamic re-assignment of data controller and processor roles, allowing credits to remain compliant even if initial verifiers change or new standards emerge.
• Continuous Trustworthiness: Ensures credits retain value and trust, with layered validation that supports multiple VVBs and allows post-issuance greenlighting as needed.
• Regulatory Resilience: Allows the registry to manage approved VVBs, maintaining a controlled but flexible approach to evolving standards and regulations.

Visual conceptualisation

If we conceptualize this structure as a three-dimensional (3D) grid, we can capture time (X-axis) as the progression of the project, VVB attestations (Y-axis) as vertical layers of verifier approvals, and MRV data (Z-axis) as supporting information for each verification step.

While Mermaid doesn’t natively support 3D diagrams, we can represent the structure conceptually by layering elements to give a sense of depth. Here’s how it could look in Mermaid syntax:

graph TD

%% Initial Issuance Flow on X (Time) and Y (Verifier Approvals) Axes
subgraph Timeline
    direction TB
    T1[Project Start]
    T1 --> T2[Initial Data Collection]
    T2 --> T3[Credit Issuance]
end

%% Verification Layers on Y-Axis for Different VVBs
subgraph Verifier_Attestations
    direction TB
    VVB1[Verification by VVB1]
    VVB2[Verification by VVB2]
    VVB3[Verification by VVB3]
end

%% MRV Data on Z-Axis (Supportive Data)
subgraph MRV_Data
    MRV1[MRV Data Supporting Project Registration]
    MRV2[MRV Data Supporting Site Creation]
    MRV3[MRV Data Supporting Claim]
end

%% Connect MRV Data (Z) to Specific VVB Verifications (Y)
MRV1 --> VVB1
MRV2 --> VVB2
MRV3 --> VVB3

%% Connect VVB Verifications (Y) to Timeline (X) Stages
T1 --> VVB1
T2 --> VVB2
T3 --> VVB3

%% Final Provenance Block
VVB1 & VVB2 & VVB3 --> Provenance[Enhanced Credit Provenance]

Loading

Concept Explanation

• X-Axis (Time/Timeline): Represents the project’s timeline, from the initial data collection (e.g., Project Start) to Credit Issuance. Each milestone in the project timeline (e.g., Project Registration, Site Creation) serves as a reference point for validation.

• Y-Axis (Verifier Attestations): Represents approvals by different qualified VVBs over time. Each VVB adds an attestation or verification layer specific to a given data point (e.g., Project Registration, Site Creation, Claim) at a particular moment in the timeline.

• Z-Axis (MRV Data): Represents the MRV (Measurement, Reporting, and Verification) data that supports each specific verification step. Each data point on the Z-axis (e.g., MRV1 for Project Registration) is associated with a particular verifier's attestation on the Y-axis, creating a support structure for the credit’s provenance.

How It Functions:

• 3D Structure for Flexibility:
  • Each X-Y pair represents a particular verifier’s approval for a specific project timeline milestone, supported by relevant MRV data on the Z-axis.
  • By allowing verifiers to independently validate specific milestones with supporting MRV data, this structure provides a robust way to establish credit provenance over time.
• Enhanced Provenance:
  • The combined contributions from all verifiers and their supporting MRV data points culminate in a final block representing Enhanced Credit Provenance. This structure ensures that, even if a particular verifier becomes inactive, the credit retains a resilient and distributed validation history.

This 3D trustchain concept allows Guardian to handle both flexible, verifier-specific attestations and detailed data support, establishing a multidimensional system that can adapt over time.

Questions for Community Feedback

• What practical challenges might arise in implementing this layered, multi-dimensional verification model within Guardian?
• How should the registry manage VVB transitions to ensure both continuity and compliance in credit validation?
• Are we able to model this flow with the current technology without changes, if so what does that look like what is the example?