SPV

SPV plays a crucial security role in the overall system operation by preventing malicious signatures caused by fraudulent information sources .

how it works: It registers on the blockchain through remote attestation , and then runs multiple blockchain light clients inside SGX to provide transaction verification services for the monitor .

It uses a key generated by SGX to sign the response, and the monitor verifies the signature through the public key registered by SPV on the chain to ensure that the SPV's response originates from a genuine SGX program with specific code .

There are two modes for SPV integration with the monitor: public and local . In public mode , all monitors can use the public SPV to verify transactions and validate the synchronization status of SPVs operating in local mode . In local mode , each monitor is paired with a dedicated SPV to ensure decentralization of verification sources and mitigate risks from malicious validators.

The public mode's role in cross-validation aligns with SPV-based structural arrangements for unified supervision, as seen in financial infrastructure projects.

The local mode's emphasis on decentralization reflects SPV design principles in distributed systems, such as those in blockchain projects, to prevent single points of failure.

Each light client is built on the open-source implementation of its corresponding blockchain to ensure security , adhering to the security requirements specified in protocols like bitcoin spv and ethereum light client solution.

Security Assurance

1. Intel SGX Remote Attestation Overview

Intel SGX Remote Attestation is a critical security feature that enables verification of the authenticity and integrity of an enclave running in an untrusted environment. This process involves three core components: the application's enclave, the Intel-provided Quoting Enclave (QE), and the Provisioning Enclave (PvE) . The attestation workflow ensures that only trusted enclaves—verified by Intel's architecture—are allowed to operate, establishing a foundation for secure computation even when the underlying OS or infrastructure is compromised.

2. Intel SGX Key Architecture

Intel SGX utilizes a layered key hierarchy to protect sensitive data. A Secret Key (e.g., the Processor Root Key ) is derived dynamically during each system boot to encrypt memory contents, reducing risks if the key is exposed. Additionally, enclaves can generate cryptographic key pairs for specific operations (e.g., signing or sealing data). These keys are isolated within the enclave and never exposed externally, ensuring confidentiality and integrity.

3. Registering the Public Key (PK) on the Blockchain

To enable trustless verification, the public key (PK) corresponding to the SGX-generated secret key is registered on a blockchain. This process typically involves:

• Remote Attestation Integration : The enclave connects to an Intel-certified Remote Attestation server (e.g., Fireblocks' SGX service) to retrieve and bind the secret key securely.

• Blockchain Registration : During the on-chain registration process, nodes verify the remote attestation and validate the enclave measurement hash (MRENCLAVE) to ensure that only programs with the specific, pre-approved code can pass verification. The PK is stored immutably on the blockchain, acting as a tamper-proof reference for verifying data origins.

4. Signing Data with the Secret Key and Blockchain Verification

Once the PK is registered:

• The enclave uses its secret key to sign data (e.g., transaction payloads or computations) internally.

• The signature and public key (PK) are appended to the response of the monitor's request. The monitor can verify the authenticity using the PK pre-registered on the blockchain, ensuring that the response content was generated within the SGX enclave, preventing forgery or tampering.

This workflow combines SGX's hardware-backed security with blockchain's decentralized trust model, ensuring end-to-end integrity and authenticity guarantees.

Scheme of verification of each chains

1. BTC's SPV (Simplified Payment Verification) Scheme

   • SPV allows lightweight Bitcoin clients to verify transactions without downloading the entire blockchain.

   • It works by downloading only block headers (80 bytes per block) and using Merkle proofs to confirm a transaction's inclusion in a specific block.

   • SPV nodes rely on full nodes to provide transaction data and proofs, but they independently validate the blockchain's consensus rules (e.g., proof-of-work, chain difficulty).

   • Security trade-offs: Vulnerable to long-range attacks if malicious full nodes withhold or falsify data, requiring SPV clients to connect to multiple peers for redundancy.

2. Ethereum's Light Client Protocol

   • Ethereum light clients (e.g., Light Ethereum Subprotocol / LES ) enable devices to interact with the network while storing only block headers and critical state data.

   • They verify header chain validity (via PoW/PoS consensus) and request specific data (e.g., account balances, smart contract states) from full nodes, which are cryptographically authenticated using Merkle Patricia Trie proofs .

   • In EIP-4895 (post-Merge), light clients rely on sync committees (randomly selected validator subsets) to validate beacon chain headers and cross-check execution layer data.

   • Security: Requires trust in the honesty of at least one honest full node ; mitigated via randomized peer sampling and fraud proofs in Layer 2 contexts.