Grid2d Recognition Algorithm: How It Powers Proof of Scan in 3dpass

Grid2d is a grid-based 3D shape recognition algorithm that converts 3D mesh cross-sections into cryptographic hashes, serving as the foundation for the ASIC-resistant Proof-of-Scan consensus in the 3dpass network.

The Grid2d recognition algorithm is the cryptographic engine behind the 3dpass blockchain's novel consensus mechanism. Implemented in the 3dpass/3dp repository, this algorithm transforms physical 3D objects into verifiable digital fingerprints, enabling a hybrid Proof-of-Scan (PoS-Scan) system that binds computational work to tangible geometry.

How the Grid2d Recognition Algorithm Works

Core Mechanism: Grid-Based Projection

At its core, Grid2d projects a 3D mesh onto a 2D grid through geometric cross-sections. The algorithm slices the model with a plane at a specific rotation angle μ, rasterizes the resulting 2D cross-section onto an 8 × 8 grid, and generates a binary pattern from the filled cells. This pattern is then hashed to produce a unique identifier. For any given rotation, the algorithm returns a ranked list of the "top N" hash IDs, capturing multiple geometric features of the object.

Algorithm Variants and Constants

The 3dpass implementation supports multiple Grid2d variants through an enumerated type system. These constants—POSCAN_ALGO_GRID2D_V2, POSCAN_ALGO_GRID2D_V3, POSCAN_ALGO_GRID2D_V3_1, and POSCAN_ALGO_GRID2D_V3A—are defined in the runtime and mapped to specific parameters including grid depth, grid size, and sector count. The variant selection determines how the external toolkit processes the mesh data, allowing for protocol upgrades while maintaining backward compatibility.

Grid2d Implementation in the 3dpass Codebase

Rust Wrapper and External Toolkit Integration

The native Rust code does not process 3D meshes directly; instead, it delegates geometric computations to the external pass3d / p3d toolkit, the official C++ reference implementation of Grid2d. In consensus/poscan_algo/src/lib.rs, the get_obj_hashes function acts as the primary interface. It accepts an algorithm ID, raw OBJ file bytes (potentially LZSS-compressed), and a pre-hash value, then invokes p3d_process_n to obtain a vector of hash strings. These strings are converted to sp_core::H256 types for use within the Substrate runtime.

Runtime Interface and Off-Chain Workers

Grid2d hash computation is exposed to the runtime through a dedicated interface defined in consensus/poscan_algo/src/lib.rs (lines 75-83). Off-chain workers and mining clients can request hash calculations via Runtime::calc_obj_hashes, passing the algorithm variant and object data. This design separates the computationally intensive geometric processing from on-chain state transitions while ensuring that all hash computations remain deterministic and verifiable by validators.

Grid2d in Proof-of-Scan Consensus

Mining: From Zero-Angle Scan to Rotation Bytes

The Proof-of-Scan mining process begins with a zero-angle scan (μ = 0). The miner selects a 3D object file and runs Grid2d with the default pre-hash (H256::default()) to obtain the first 10 hashes. The first hash in this list serves as the geometric nonce. This hash is mixed with the block's pre_hash using the RandomX algorithm to derive rotation_bytes, which determine the target rotation angle μ = x for the second scan.

Verification and Double-Hash Logic

During the mining loop, the object is re-scanned at the derived rotation angle μ = x, producing a second set of hashes (poscan_hash). The miner must find a pre-hash such that the double hash—the concatenation of pre_hash and poscan_hash—meets the current network difficulty (hash_meets_difficulty).

During block validation, the consensus engine re-computes the Grid2d hashes using get_obj_hashes and verifies that the stored hashes match the computed ones. The verification logic in consensus/poscan_grid2d/src/lib.rs (functions verify_v1 and verify_v2, lines 435-452 and 653-672) handles different algorithm variants, selecting either the pre_hash or parent hash as the rotation seed depending on whether the variant is V3_1 or V3A versus legacy versions.

ASIC Resistance Through Physical Object Binding

Grid2d provides ASIC and FPGA resistance by binding the mining puzzle to physical 3D geometry. Unlike traditional Proof-of-Work that relies purely on computational hashing, Proof-of-Scan requires miners to possess and scan actual 3D object files. Changing even a single vertex in the mesh alters the Grid2d output, invalidating the mining attempt. This creates a "physical proof" layer that general-purpose mining hardware cannot optimize without access to the specific geometric data.

Code Examples

Computing Grid2d Hashes for a 3D Object

use sp_core::H256;
use poscan_algo::{get_obj_hashes, POSCAN_ALGO_GRID2D_V3_1};

// `obj_bytes` – raw .obj file contents (may be LZSS-compressed)
let algo_id = POSCAN_ALGO_GRID2D_V3_1;          // choose the desired variant
let pre_hash = H256::default();                // zero-angle scan uses the default

// Compute the top-10 Grid2d hashes
let top_hashes: Vec<H256> = get_obj_hashes(&algo_id, &obj_bytes, &pre_hash, false);
// `top_hashes[0]` is the "zero-angle" hash used for the rotation bytes

Source: consensus/poscan_algo/src/lib.rs – lines 94-106 and 188-210.

Verifying a Seal Inside the Consensus Engine

fn verify_v1(
    &self,
    ver: RuntimeVersion,
    parent: &H256,
    pre_hash: &H256,
    pre_digest: Option<&[u8]>,
    seal: &RawSeal,
    difficulty: U256,
    psdata: &PosscanDataV1,
) -> Result<bool, Error<B>> {
    // … decode SealV1, check poscan_hash, difficulty, signature …

    // Determine which pre-hash to use for the second Grid2d run
    let h = if psdata.alg_id == POSCAN_ALGO_GRID2D_V3_1
            || psdata.alg_id == POSCAN_ALGO_GRID2D_V3A {
        pre_hash                // use the current block’s pre-hash
    } else {
        parent                  // legacy behaviour
    };

    // Re-calculate the Grid2d hashes for the selected rotation
    let computed_hashes = get_obj_hashes(&psdata.alg_id, &psdata.obj, h, true);
    if computed_hashes != psdata.hashes {
        return Ok(false);
    }
    // … further signature and rotation checks …
    Ok(true)
}

Source: consensus/poscan_grid2d/src/lib.rs – lines 435-452 (v1) and 653-672 (v2).

Using the Runtime Interface from an Off-Chain Worker

use sp_consensus_poscan::HashableObject;

/// Off-chain code that asks the runtime to compute Grid2d hashes.
let alg = sp_consensus_poscan::POSCAN_ALGO_GRID2D_V3_1;
let obj_data = /* … load .obj … */;
let pre = H256::default(); // zero-angle

let hashes = Runtime::calc_obj_hashes(&alg, &obj_data, &pre);
// `hashes` is a `Vec<H256>` ready for inclusion in a PoW seal.

Source: Runtime interface defined in consensus/poscan_algo/src/lib.rs – lines 75-83.

Key Files and Architecture

File	Purpose
consensus/poscan_grid2d/src/lib.rs	Core PoW verification, seal handling, double-hash logic, and integration of Grid2d results into the consensus engine.
consensus/poscan_algo/src/lib.rs	Wrapper around the external p3d toolkit, defines get_obj_hashes, algorithm variant constants, and the runtime interface.
consensus/poscan/README.md	High-level description of Proof-of-Scan, the Grid2d → RandomX pipeline, and ASIC-resistance rationale.
pallets/poscan/README.md	Documentation of on-chain PoscanData structures, object category enums, and hash storage in extrinsics.
primitives/evm/src/lib.rs	Mapping of algorithm IDs (POSCAN_ALGO_GRID2D_*) to runtime enumerations used by the EVM precompile.

These files illustrate the complete lifecycle of the Grid2d recognition algorithm—from raw 3D mesh to on-chain proof—forming the cryptographic backbone of the Proof-of-Scan consensus.

Summary

• Grid2d is a grid-based 3D shape recognition algorithm that rasterizes mesh cross-sections onto an 8×8 grid to produce cryptographic hashes.
• The algorithm is implemented in the 3dpass/3dp repository through a Rust wrapper in consensus/poscan_algo/src/lib.rs that interfaces with the external p3d toolkit.
• Multiple variants exist (V2, V3, V3_1, V3A) to support protocol evolution while maintaining backward compatibility.
• In Proof-of-Scan consensus, Grid2d enables ASIC-resistant mining by binding computational work to physical 3D geometry through a two-phase scanning process (zero-angle and rotation-derived).
• Verification re-computes Grid2d hashes during block import to ensure the miner performed the required geometric work.

Frequently Asked Questions

What makes Grid2d ASIC-resistant?

Grid2d achieves ASIC resistance by requiring miners to process actual 3D object files rather than performing pure mathematical hashing. The algorithm must slice a specific mesh at precise rotation angles and rasterize the cross-section, an operation that requires loading and parsing geometric data. Since changing a single vertex alters the entire hash output, specialized hardware cannot optimize the mining process without access to the specific 3D models, effectively binding the proof-of-work to physical object geometry.

How does the zero-angle scan differ from the mining rotation scan?

The zero-angle scan (μ = 0) occurs at the beginning of the mining process using a default pre-hash (H256::default()). This scan produces the initial set of hashes, with the first hash serving as the geometric nonce. This nonce is then mixed with the block's pre-hash via RandomX to derive rotation bytes, which determine the target angle μ = x for the second scan. The mining rotation scan computes the final poscan_hash that must satisfy the difficulty target when combined with the pre-hash in a double-hash construction.

What are the differences between Grid2d V3, V3_1, and V3A variants?

The Grid2d variants represent evolutionary improvements to the recognition algorithm while maintaining consensus compatibility. POSCAN_ALGO_GRID2D_V3 established the baseline grid-based projection system. POSCAN_ALGO_GRID2D_V3_1 and POSCAN_ALGO_GRID2D_V3A introduced changes to how the rotation pre-hash is selected during verification—specifically, these newer variants use the current block's pre_hash rather than the parent hash to derive rotation angles. This distinction is handled in the verification logic at consensus/poscan_grid2d/src/lib.rs to ensure proper validation across different algorithm versions.

Where is the actual Grid2d computation performed if not in the Rust code?

The actual geometric processing occurs in the external pass3d (or p3d) toolkit, a C++ reference implementation of the Grid2d algorithm. The 3dpass Rust codebase acts as a wrapper that forwards raw OBJ data to this external library via the poscan_algo crate. Specifically, the get_obj_hashes function in consensus/poscan_algo/src/lib.rs calls p3d_process_n to obtain hash vectors, which are then converted to sp_core::H256 types for use in the Substrate-based consensus engine.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}