[Quais] - ProgPow Verification with Go Implementation compiled to WASM

[mibuono]

Notes

[rileystephens28]

Proposal for Refactoring ProgPoW Cache Management

Objective

The goal of this proposal is to refactor the ProgPoW implementation taken from go-quai to remove memory mapping in favor of an in-memory cache management system. This change aims to make the ProgPoW verification compatible with environments that do not support memory mapping, namely WebAssembly. The new design should allow cache storage and retrieval to be handled externally, with the capability to generate the cache in memory if one is not provided.

Changes to Function Signatures and Data Structures

Data Structures

A modified cache data structure that is no longer concerned with memory mapping.

type cache struct {
    epoch uint64   // Epoch for which this cache is relevant
    cache []uint32  // The actual cache data content
    CDag  []uint32 //  The cDag used by progpow. May be nil
    once  sync.Once // Ensures the cache is generated only once
}

Function Signature Modifications

Modify the VerifySeal function to accept a cache pointer as an optional parameter. This change allows the caller to provide a precomputed cache.

func (progpow *Progpow) VerifySeal(header *types.Header, cache *cache) (common.Hash, error)

Removal of Memory Mapping

• Eliminate all memory mapping logic from the ProgPoW package. This includes removing the memoryMapFile and memoryMapAndGenerate functions, along with any related code that deals with file I/O for cache management.
• Refactor any functions that relied on memory-mapped files to use the new Cache data structure.

External Cache Management

The responsibility for cache management will shift to the caller. This includes:

• Storing the cache externally after it is computed (in the case where cache is generated rather than provided).
• Providing a previously stored cache to VerifySeal when available to avoid unnecessary regeneration.

Benefits

• Compatibility: Makes the ProgPoW verification package compatible with environments lacking file I/O capabilities, such as WebAssembly.
• Flexibility: Allows external systems more control over cache management, enabling optimizations based on the specific use case.

Considerations

• Memory Usage: Direct in-memory management of the cache may lead to increased memory usage.
• Cache Validity: Implementers must ensure the provided cache is valid for the block being verified.

CC @wizeguyy