# HVR

### Initial

HVR (short for Hashed Validation Reference) is an extension pattern to minimize the attack surface of the core pattern (TVA) - especially in the case of a compromise of the validation layer.

***

### Problem statement

If you use TVA as a core pattern, you have defined roles and tasks, as well as a very robust base, but also a clear problem: If the L2 (Validation Layer) is compromised, it can ultimately create fake requests and forward them to L3 (Execution Layer).\
\
The HVR pattern pursues the purpose of preventing exactly this.

***

### Pattern description

The HVR pattern incorporates an additional mechanism - or step - to protect against the validation layer acting as a single point of compromise. As soon as L1 initiates the request, it hashes it before passing it on to L2 (the validation layer). It then forwards this hash to the HVR add endpoint of L3.

L3 then adds this hash, along with a timestamp and an expiration date/time (e.g., timestamp +5 minutes), to the HVR table (a simple database or file).

Once L2 has received the actual request from L1, it can validate it and forward it to L3 if it has been successfully validated. L3 then hashes the request and checks whether it is in the HVR table and whether the expiration time has not yet been reached. Once the hash is found, it is of course immediately removed from the table, even before execution begins, to prevent recall attacks.

It is important to note that L1 can only communicate with L3 using the HVR add endpoint.And, most importantly, L2 cannot communicate with L3’s HVR endpoint - without exception.&#x20;

The basic flow remains sequential, but with the add-on, L1 sends the HVR to L3 during initialization before the step of communicating with L2. (L1 -> L3; L1 -> L2 -> L3)

Below is a diagram illustrating the structure and flow of a request using the HVR pattern based on TVA:

<figure><img src="https://content.gitbook.com/content/1t3EXCJKTJuA3880qJZT/blobs/E1pUQGEnYcxIBV1fboDA/HVR_Pattern_Orbix_Labs.drawio.svg" alt=""><figcaption></figcaption></figure>

This means that neither L1 nor L2 alone can send malicious requests to L3. Only L1 is able to register HVR hashes with L3, and requests are only considered for execution when they arrive from L2 and match a hash in the HVR table. Therefore, L1 and L2 are both required to trigger any execution in L3.
