Havenlon defines an execution control architecture rooted in hardware. The system does not rely on the trustworthiness of the software environment; instead, it utilizes multi-layered constraint mechanisms to confine the execution authority within physically controllable boundaries. Execution authority is granted only when all security conditions are simultaneously satisfied.

2.2 Layered Architecture

This system consists of four layers:

2.2.1 Security Model Layer

Defines system security and execution admission conditions:

· System Security Function: $S_{t}$

· Request Admission Function: $A ccess (R)$

2.2.2 Isolation & Trust Layer

Defines execution boundaries and key protection mechanisms:

· Hardware Root of Trust (RoT)

· Tri-Domain Isolation Architecture (REE / Arbiter / SEE)

· Key Lifecycle and Physical Binding

2.2.3 Decision Layer

Defines whether the execution is valid :

· Execution Decision Function: $E_{f ina l}$ (τ)

· Multi-Policy Risk Control Model (Cloud / Edge / Physical)

· Veto Principle

2.2.4 Execution Layer

Defines the execution path and non-bypassability mechanisms:

· Standard Operating Procedure (SOP)

· Multi-Party Authorization and Multi-Signature Mechanism

· Hardware Final Execution Adjudication

2.3 Execution Control Principle

The system's execution authority is jointly determined by multiple factors:

$E x ec u t i o n = A ccess (R) \land E_{f ina l} (τ) \land S O P$

This formula defines the prerequisite conditions for the system's ultimate execution authority to be valid . Execution evaluates to true only when the request passes admission verification ( $A ccess (R)$ ), the execution decision is valid ( $E_{f ina l} (τ)$ ), and it satisfies the standard operating procedures (SOP). If any single condition is unmet, the $S O P$ MUST be rejected, and it MUST NOT proceed to subsequent execution paths.

2.4 Constraints

The system MUST:

· Requests that fail admission verification MUST NOT enter the Decision Layer.

· Requests that fail the decision function MUST NOT enter the Execution Layer.

· Requests that do not meet the execution SOP MUST NOT be executed.

2.5 Non-Bypassability

The system MUST:

· The execution path MUST NOT be bypassed or skipped.

· Decision results MUST NOT be forged.

· The software layer MUST NOT bypass hardware execution.

2.6 Security Boundary

The system's security boundary is collectively composed of the following components:

· Hardware Root of Trust (Hardware RoT)

· Policy Decision Model ( $E_{f ina l}$ )

· Execution SOP Constraints

2.7 Design Objectives

The system MUST achieve the following objectives:

· Decentralization of Execution Authority: No single point of control exists.

· Policy Orthogonality: Different security factors are independent of each other.

· Hardware Constraints: Execution MUST undergo physical verification.

· Auditability: All decisions and executions are verifiable.

3 Hardware-Rooted Trust Architecture

3.1 Abstract

This system extends the Zero Trust architecture from "Access Control" to "Execution Control," establishing non-bypassable constraints on execution authority at the hardware layer. The system does not rely on the security of network boundaries. All execution requests MUST be verified in an untrusted environment and are permitted to execute only when hardware constraints are satisfied. This architecture builds a trusted execution system through the following mechanisms:

· Hardware Root of Trust (RoT)

· Cryptographic Orthogonality

· Dual-Layer Edge-Cloud Audit

The system MUST:

· Physical Anti-Cloning

· Resistance to Man-in-the-Middle (MITM) attacks

· Non-repudiation of execution results

3.2 The Core Security Paradigm

System security is defined as a combinatorial function of cascaded constraints:

$S_{t} = P h y s i c a l \otimes C o n t r a c t + A u d i t - Δ H_{e n v}$

Where：

· Physical: Hardware Trust Factor

· Contract: Intent Binding Factor

· Audit: Audit Factor

· $Δ H_{e n v}$ : Security Entropy Loss introduced by the untrusted execution environment

3.2.1 Security Constraint Definitions

The system MUST satisfy the following conditions:

· The failure of any single component MUST NOT lead to the leakage of execution authority.

· Security MUST NOT rely on the trustworthiness of the software environment.

· Execution authority MUST be hardware-constrained.

3.3 Nomenclature & Mechanisms

3.3.1 Physical Constraint ⊗

Physical trust consists of the following components:

· Secure MCU

· Gateway Hub

The system MUST:

· If either component is compromised, it MUST NOT extract key material.

· The relationship between the two MUST constitute an orthogonal security relationship, rather than a linear superposition.

3.3.2 Contract Verification

The system implements an authentication mechanism based on Passkey / FIDO2. The system MUST:

· All operations MUST be bound to explicit user intent.

· Signatures MUST be consistent with the operation content.

· Blind signing MUST NOT be permitted.

3.3.3 Audit Mechanism

The system adopts a dual-layer audit structure:

· Edge Audit（ $A_{H u b}$ ）

· Cloud Audit（ $A_{S aa S}$ ）

3.3.3.1 Edge Audit MUST

· Verify local communication link integrity.

· Detect physical connection anomalies.

· Filter high-frequency abnormal behaviors.

3.3.3.2 Cloud Audit MUST

· Execute global risk control policies.

· Analyze cross-device behaviors.

· Manage device lifecycles.

3.3.4 Environmental Risk Factors（ $Δ H_{e n v}$ ）

The system MUST assume the following risks are perpetually present:

· Operating System (OS) vulnerabilities

· Side-Channel Attacks (SCA)

· Network eavesdropping / sniffing

System security MUST NOT depend on the elimination of these risks.

3.4 Key Derivation & Storage

3.4.1 Key Protection Model

The system MUST adopt a UID-bound key encapsulation mechanism.

3.4.1.1 Key Derivation

The derived key is defined as:

$K_{d er i v} = H K D F (P B K D F 2 (P I N ∥ S a l t_{T R N G}, I t er \geq 200000) ∥ U I D_{S E})$

The system MUST:

· $K_{d er i v}$ ：Derived Key, the intermediate key used for subsequent decryption or signing operations.

· $P I N$ ：User Secret, serving as the source of password entropy.

· $S a l t_{T R N G}$ ：Random salt generated by the hardware True Random Number Generator (TRNG), used to enhance resistance against brute-force attacks.

· $I t er$ ：PBKDF2 iterations, which MUST meet the security strength requirements for brute-force resistance ( $Iter ge 200000$ ）

· $U I D_{S E}$ ：Unique Identifier of the Secure Element, used to bind the device's physical identity.

· $P B K D F 2 (\cdot)$ ：Password-Based Key Derivation Function, used to generate a brute-force-resistant intermediate key from low-entropy input (PIN).

· $H K D F (\cdot)$ ：HMAC-based Extract-and-Expand Key Derivation Function, used to fuse multiple input factors and generate the final derived key.

· The derived key $K_{d er i v}$ MUST depend simultaneously on the user secret factor and the device's physical identity; no single factor shall independently constitute a valid key.

3.4.1.2 Key Decryption

$K_{sess i o n} = D e c_{A E S - GC M} (K_{d er i v}, C_{S E})$

· $K_{sess i o n}$ ：Session Key, used for subsequent encrypted communication or signing operations.

· $K_{d er i v}$ ：Derived Key, jointly generated by the PIN and device identity.

· $C_{S E}$ ：Encrypted Payload encapsulated by the Secure Element.

· $D e c_{A E S - GC M} (\cdot)$ ：Authenticated Decryption function based on AES-GCM.

The system MUST:

· Decryption MUST include an Authentication Tag (Auth Tag).

· An incorrect PIN MUST result in decryption failure.

· Decryption failure MUST NOT produce any valid state.

3.5 Anti-Cloning Constraints

The system MUST:

· Keys are bound to the device's physical UID.

· Copying Flash data MUST NOT recover the key.

· Keys MUST NOT be migratable between different devices.

3.6 Dynamic Attestation

3.6.1 Access Control Function

$A ccess (R) = (C er t \in R oo t \land S i g_{v a l i d} \land Δ C \geq 0)$

$A ccess (R)$ defines the admission conditions for a request. $A ccess (R)$ $= 1$$ only when the device certificate is trusted ( $C er t \in R oo t$ ), the request signature is valid ( $S i g_{v a l i d}$ ), and the state has not rolled back ( $Δ C \geq 0$ ); otherwise, $A ccess (R)$ $= 0$ . If any single condition is unmet, the request MUST be rejected, and it MUST NOT enter the execution path.

3.6.2 System Constraints

The system MUST:

· All devices MUST possess a trusted certificate chain.

· All requests MUST carry a signature.

· Monotonic counters MUST NOT be rolled back.

3.6.3 Attack Resistance

The system MUST be capable of detecting and rejecting:

· Replay attacks

· Cloned devices

· Forged devices

3.7 Dual-Mode Transport Layer Security

3.7.1 Mode Definitions

The system supports two modes:

3.7.1.1 Mode A: Cloud-Centric

SaaS participates in decision-making but does not constitute the root of trust.
Hub acts solely as an encrypted channel.

3.7.1.2 Edge-Centric

· Hub serves as the trust anchor.

· Verification is completed directly locally.

3.7.2 Security Constraints

The system MUST:

· The execution path is non-bypassable under either mode.

· Keys are never exposed under either mode.

3.7.3 Security Differential

$Δ η = η_{C l o u d} - η_{E d g e}$

$Δ η$ represents the security differential between the cloud mode and the local mode, where $η_{C l o u d}$ is the security coefficient of the Cloud-Centric mode, and $η_{E d g e}$ is the security coefficient of the Edge-Centric mode.

In uncontrolled environments, the cloud mode possesses higher security; in controlled environments, the security of both tends to be equivalent.

The system MUST:

· Uncontrolled environments prioritize the use of Cloud-Centric mode.

· Controlled environments permit the use of Edge-Centric mode.

3.8 Conclusion

In an untrusted execution environment, this system establishes security boundaries through the following mechanisms:

· Hardware Root of Trust

· Dynamic Remote Attestation

· Physical Key Binding

The system MUST:

· The cost of attack is elevated from the software level to the physical level.

· Execution paths are non-bypassable.

· Keys MUST NOT be cloned or exported.

4 Security Philosophy

This system is built upon the principles of "Zero Trust" and "Defense-in-Depth". The system does not rely on the security of network boundaries and MUST assume that:

· The external network environment is untrusted.

· The Operating System (OS) may be fully compromised.

The system ensures that core assets maintain their confidentiality and integrity under the aforementioned conditions through a Hardware Root of Trust and multi-domain physical isolation mechanisms.

4.1 Core Constraints

The system MUST:

· Core assets (private keys and signing logic) MUST NOT be exposed to untrusted environments.

· Even if the OS is granted Root privileges, attackers MUST NOT be able to access, extract, or tamper with core assets.

4.2 Threat Model and Defense Boundary

4.2.1 Assumed Attack Vectors

The system MUST assume the existence of the following attack capabilities:

· Logical Layer Attacks: OS Privilege Escalation (Root Exploit), Remote Code Execution (RCE), Man-in-the-Middle (MITM) attacks.

· Physical Layer Attacks: Debug Interface Intrusion (JTAG/UART), Bus Sniffing, Flash Extraction.

· Side-Channel Attacks (SCA): Power Analysis (DPA/SPA), Electromagnetic (EM) Analysis, Fault Injection (Glitching).

4.2.2 Defense Objectives

The system MUST:

· The physical isolation and logical decoupling of the Computation Environment and the Key Environment.

4.3 Tri-Domain Isolation Architecture

The system adopts a tri-domain physical isolation architecture; communication between domains is strictly permitted only through controlled channels.

4.3.1 Rich Execution Environment(REE)

· Hardware Carrier: Application Processor (Linux SoC)

· Security Level: Untrusted Zone

Responsibilities:

· Network Communication (TCP/IP, TLS)

· Data Encoding/Decoding

· User Interaction

Constraints:

· MUST NOT store any plaintext private keys.

· MUST NOT execute any signing operations.

4.3.2 Security Arbiter Domain

· Hardware Carrier: MCU + Secure Element

· Security Level: Trust Boundary

Responsibilities:

· Perform validity verification on all external requests.

· Establish and maintain encrypted communication channels.

· Pre-process sensitive data securely entering the core domain.

Constraints:

· Requests that fail verification MUST NOT enter the core execution domain.

4.3.3 Secure Execution Environment(SEE)

· Hardware Carrier: Isolated Security Core

· Security Level: Protected Zone

Responsibilities:

· Perform cryptographic signing operations.

· Execute key derivation.

· Process sensitive data.

Constraints:

· MUST ONLY accept instructions from the Arbiter Domain.

· MUST NOT directly expose internal states.

4.4 Key Lifecycle

4.4.1 Key Generation

The system MUST:

· Private keys MUST be generated by a hardware True Random Number Generator (TRNG).

· Private keys MUST be generated internally within the secure chip.

· Private keys MUST NOT appear in plaintext on external buses or in memory.

4.4.2 Key Usage & Storage

The system MUST:

· All key operations MUST be completed internally within the secure chip.

· Private keys MUST possess a non-exportable attribute.

· External systems MUST NOT access private keys.

4.4.3 State Protection

The system MUST:

· Monotonic counters to prevent state rollback.

· Session key mechanisms to prevent replay attacks.

4.5 Secure Pipeline

This specification defines the following execution path:

1. The Cloud encrypts and encapsulates the request.

2. The REE acts as a transparent relay.

3. The Arbiter Domain executes verification and decryption.

4. The Core Domain executes the operation.

5. The result is returned in ciphertext format.

5 Security Constraints

The system MUST:

· Data remains encrypted at all times during transmission.

· Unauthorized nodes MUST NOT be able to parse plaintext data.

· Bus sniffing MUST NOT yield any valid information.

5.1 Physical and Supply Chain Security

5.1.1 Active Physical Defense

The system SHOULD possess:

· Anomaly detection capabilities for voltage, temperature, and frequency.

· A secure zeroization mechanism triggered by anomaly detection.

5.1.2 Supply Chain Trust

The system MUST:

· Each device possesses a unique certificate chain.

· The system supports Secure Boot.

· Unsigned firmware MUST NOT be executed.

5.2 Conclusion

This architecture achieves physical constraints on the execution environment through a Hardware Root of Trust and multi-domain isolation mechanisms.

The system MUST:

· Core assets are not exposed to untrusted environments.

· The execution path cannot be bypassed.

· The cost of attack is elevated from the software level to the physical level.

6 Dynamic Policy & Risk Control

6.1 Overview

This system defines an execution control model based on multi-policy sources. System security does not rely on a single policy node, but is jointly determined by multiple independent security factors. Execution authority is granted only when all necessary conditions are simultaneously satisfied.

6.2 Core Principles

The system MUST:

· Execution decisions are jointly determined by multiple independent policy sources.

· The failure of any single policy MUST result in execution failure.

· Policy verification MUST cover identity, intent, and environment.

6.3 Separation of Communication and Decision

The system MUST distinguish between the communication layer and the decision layer:

6.3.1 Communication Layer

Responsibilities:

· Ensure the request can be transmitted intact.

· Does not participate in execution decisions.

6.3.2 Decision Layer

Responsibilities:

· Determine whether the request meets the execution conditions.

· Output the final execution permission.

6.3.3 Constraints

The system MUST:

· Successful communication MUST NOT directly lead to execution.

· Execution MUST rely on the output of the decision layer.

6.4 Execution Decision Model

This specification defines execution authority as the following function:

$E_{f ina l} (τ) = I_{u ser} (τ) \cdot Π_{c l o u d} (τ) \cdot Π_{e d g e} (τ) \cdot Φ_{p h y} (τ)$

Where：

· τ: Represents the Execution Context.

· All factors evaluate to ${0, 1}$ .

6.4.1 Intent Integrity

$I_{u ser} (τ) = V er i f y (S i g, H a s h (t x))$

The system MUST perform verification of:

· The user signature is consistent with the operation content.

· Blind signing MUST NOT be permitted.

6.4.2 Cloud Policy

$Π_{c l o u d} (τ) = C h ec k_{R B A C} \land B l a c k l i s t \land Gl o ba l L imi t s$

The system MUST perform verification of:

· Account permissions are valid and authorized.

· The target has not hit the blacklist.

· Global quota limits are satisfied.

6.4.3 Edge Policy

$Π_{e d g e} (τ) = C h ec k_{O f f l in e W hi t e l i s t} \land P r i v a cy L imi t s \land G eo F e n ce$

The system MUST perform verification of:

· The address is in the local whitelist.

· Private quota policies are satisfied.

· Geolocation constraints (Geofence) are satisfied.

6.4.4 Physical Constraints

$Φ_{p h y} (τ) = C h ec k_{A n t i T am p er} \land P o w er I n t e g r i t y \land L i f ecy c l e$

The system MUST perform verification of:

· The device has not been physically tampered with.

· Power and clock states are normal.

· The lifecycle state is valid and authorized.

6.5 Veto Principle

The system implements logical conjunction (AND):

$E_{f ina l} (τ) = 0, if any factor = 0$

6.6 Constraints

The system MUST:

· The failure of any factor MUST terminate the execution.

· There MUST NOT exist a single-point allowance path.

6.7 Policy Model

The system adopts an Attribute-Based Access Control (ABAC) model.

6.7.1 Asset Constraints

The system MUST:

· Restricting chain types and asset types.

· Restricting target contract addresses.

· Address whitelist mechanisms.

6.7.2 Routing and Target Constraints

The system MUST:

· Restricting chain types and asset types.

· Restricting target contract addresses.

· Address whitelist mechanisms.

6.7.3 Context Constraints

The system MUST:

· Time window controls.

· Network and geographic fences (Geofencing).

6.7.4 Role & Quorum Constraints

The system MUST:

· Role-Based Access Control (RBAC).

· Multi-signature authorization (M-of-N Quorum).

6.8 Dual Policy Engine

The system adopts a dual-policy architecture combining Cloud and Edge.

6.8.1 Cloud Engine

Responsibilities:

· Execute global risk control.

· Manage authorization workflows.

· Provide blacklisting and behavioral analysis.

6.8.2 Edge Engine

Responsibilities:

· Execute local private policies.

· Support offline operations.

· Ensure policies are non-bypassable.

6.9 Constraints

The system MUST:

· Local policies remain effective under offline conditions.

· The Cloud policy CANNOT bypass the local policy.

· The failure of either policy MUST block execution.

6.10 Decision Workflow

The execution workflow is as follows:

1. The user initiates a request.

2. The Cloud executes Level-1 risk control.

3. The Edge executes Level-2 risk control.

4. Decision results are aggregated.

5. The core execution domain executes the operation.

6.11 Constraints

The system MUST:

· All policies are verified prior to execution.

· Requests that fail policy verification MUST NOT be executed.

6.12 Conclusion

Through the combination of multi-policy factors, the system achieves strict constraint over execution authority. The system MUST:

· Execution authority is jointly determined by multiple factors.

· The failure of any single factor immediately blocks execution.

· Execution paths CANNOT be bypassed.

7 Enterprise-Grade Execution Control Standard (SOP)

7.1 Overview

This system constrains critical operations through process governance.

All critical operations (including high-risk operations, whitelist modifications, and policy adjustments) MUST pass through the following unidirectional execution chain:

Initiation → Cloud Audit → Authorization → Hardware Execution

7.2 Core Constraints

The system MUST:

· All critical operations MUST pass through the complete execution chain.

· If any stage is missing, the operation MUST NOT be executed.

· The execution chain MUST NOT be bypassed or reverted.

7.3 Authority Principle

The system MUST: No single role, single system, or single administrator possesses the ultimate disposal right over assets (Decentralization of Authority).

7.4 PIN Verification Mechanism (Local Verification)

The system implements a hardware-based local verification mechanism.

7.5 Constraints

The system MUST:

· PIN verification is completed solely within the Secure Element (SE).

· The PIN MUST NOT be uploaded to the cloud.

· The PIN MUST NOT be stored in the Operating System (OS) or cache.

7.6 Security Attributes

The system MUST:

· Only the verification result is transmitted over the network; the PIN itself is NOT transmitted.

· Network data MUST NOT be used to reverse-engineer or derive the original PIN.

7.7 4-Stage Execution Flow

7.7.1 Stage 1: Initiation

Role: Operator

The system MUST:

· The request MUST be initiated by a bound device.

· Request parameters are locked upon initiation.

· Parameters MUST NOT be modified in subsequent workflows.

7.7.2 Stage 2: Cloud Audit

Role: SaaS System

The system MUST:

· Blacklist validation.

· Risk control rule validation (e.g., time windows, quotas).

· Authorization workflow routing.

7.7.3 Stage 3: Authorization (Synergistic Approval)

Role: Approver

The system MUST:

· Authorization MUST be completed on an independent device.

· Authorization MUST display the complete operation content.

· Blind signing MUST NOT be permitted.

7.7.3.1 Multi-Signature Constraints

· The system MUST:

· M-of-N multi-signature mechanisms.

· High-risk operations MUST satisfy multi-signature conditions.

7.7.4 Stage 4: Execution

Role: Hardware Root of Trust (Secure Execution Domain)

The system MUST:

· Verify the integrity of all signatures prior to execution.

· Validate the integrity of the execution chain.

7.7.4.1 Execution Constraints

The system MUST:

· The failure of any validation MUST result in execution rejection.

· The hardware MUST possess the final adjudication right.

· Software MUST NOT bypass hardware execution.

7.8 Execution Veto Mechanism

The system MUST:

· An anomaly in any segment MUST trigger execution abortion.

· Aborted operations MUST NOT yield partial execution results (Atomicity).

· Degraded execution paths MUST NOT exist.

7.9 Resilience in Anomalous Scenarios

7.9.1 Scenario 1: Cloud Account Compromise

The system MUST:

· Signatures CANNOT be completed without a physical device.

· A single cloud command MUST NOT trigger execution.

7.9.2 Scenario 2: Insider Privilege Abuse

The system MUST:

· Separation of Duties (SoD) between initiation and authorization.

· A single individual CANNOT complete the entire execution chain.

· Multi-signature mechanisms cover high-risk operations.

7.9.3 Scenario 3: Network Attacks (MITM)

The system MUST:

· Communication link encryption via mTLS (Mutual TLS).

· All requests possess End-to-End (E2E) signatures.

· Data tampering MUST be detected and rejected.

7.10 Conclusion

The system achieves enforced control over critical operations through process constraints and hardware execution mechanisms.

The system MUST:

· The integrity of the execution chain CANNOT be bypassed.

· Authority is decentralized; no single point of control exists.

· All operations possess auditability and verifiability.

· Isolation & Trust Layer: Provides execution boundaries and key protection.

· $E_{f ina l}$ (τ): Defines execution decision conditions.

· SOP: Defines the execution path.

8.3 Convergence Constraints

The system MUST:

· All executions MUST pass admission verification.

· All executions MUST satisfy the decision model.

· All executions MUST follow standard operating procedures.

8.4 Execution Control Closed-Loop

The system forms the following closed-loop:

$R e q u es t \to A ccess \to D ec i s i o n \to E x ec u t i o n \to A u d i t$

8.5 System Constraints

The system MUST:

· Failure at any stage MUST terminate execution.

· Bypass paths MUST NOT exist.

· Execution MUST be verifiable and auditable.

8.6 Summary of Security Attributes

The system MUST possess the following attributes:

· Non-Bypassability

· Multi-Factor Execution

· Decentralization of Authority (No Single Point Control)

· Hardware-Enforced Execution

8.7 Architecture Summary

This system achieves strict control over execution authority through multi-layered security constraints. Execution authority does not belong to any single component, but is jointly determined by:

· Identity Verification

· Policy Decision

· Process Constraints

· Hardware Execution

Havenlon Execution Architecture

3.3.1 Physical Constraint ⊗

3.3.3.1 Edge Audit MUST

3.3.3.2 Cloud Audit MUST

3.3.4 Environmental Risk Factors（ΔHenv​）

3.4.1.1 Key Derivation

3.4.1.2 Key Decryption

3.6.2 System Constraints

3.6.3 Attack Resistance

3.7.1.1 Mode A: Cloud-Centric

3.7.1.2 Edge-Centric

3.7.2 Security Constraints

3.7.3 Security Differential

4.2.1 Assumed Attack Vectors

4.2.2 Defense Objectives

4.3.1 Rich Execution Environment(REE)

4.3.2 Security Arbiter Domain

4.3.3 Secure Execution Environment(SEE)

4.4.1 Key Generation

4.4.2 Key Usage & Storage

4.4.3 State Protection

5.1.1 Active Physical Defense

5.1.2 Supply Chain Trust

6.4.1 Intent Integrity

6.4.2 Cloud Policy

6.4.3 Edge Policy

6.4.4 Physical Constraints

6.7.2 Routing and Target Constraints

6.7.4 Role & Quorum Constraints

6.10 Decision Workflow

7.7.1 Stage 1: Initiation

7.7.2 Stage 2: Cloud Audit

7.7.3.1 Multi-Signature Constraints

7.7.4.1 Execution Constraints

7.10 Conclusion

3.3.4 Environmental Risk Factors（ $Δ H_{e n v}$ ）