Runtime Compilation Proof-of-Work for Anti-ASIC Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional proof-of-work systems are vulnerable to circumvention by attackers using more computational power or specialized hardware, such as ASICs, which can quickly solve problems and overwhelm server systems, leading to disproportionate burdens in defending against denial-of-service attacks and other malicious activities.
Innovation Solution
A proof-of-work system based on runtime compilation is implemented, where a server generates a proof-of-work problem by partitioning key generation code into code blocks, shuffling them, and requiring clients to reorder them correctly to solve the problem, making the process computationally expensive and less susceptible to attacks with specialized hardware.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional proof-of-work systems are used, then request rate limiting is achieved, but the system becomes vulnerable to circumvention by attackers using specialized hardware or computational power
Solution Approach 1:
The patent divides the key generation code into multiple code blocks that must be assembled in the correct order. This segmentation makes the proof-of-work problem resistant to specialized hardware attacks because the computational task requires sequential assembly and runtime compilation of code blocks, a process that is difficult to optimize with ASICs or specialized hardware. Each code block contains specific logic that must be correctly ordered to generate the valid key, creating a computational barrier that is not easily circumvented.
Solution Approach 2:
The patent changes the nature of the computational task from traditional cryptographic hash puzzles to a runtime code assembly problem. By transforming the proof-of-work mechanism into a code compilation and execution challenge, the system raises the barrier for attackers using specialized hardware. The problem requires interpreting and assembling code blocks dynamically, a task that is computationally intensive and not efficiently solvable by dedicated hardware designed for traditional proof-of-work algorithms.
2Productivity
If clients perform computationally expensive proof-of-work to submit requests, then request rate is slowed down, but legitimate users experience increased latency
Solution Approach 1:
The patent implements proof-of-work at the client side with carefully tuned computational parameters. The code blocks are designed to provide sufficient security against attacks while keeping the computational burden manageable for legitimate users. The system performs partial proof-of-work by dividing the key generation into discrete code blocks that must be assembled, rather than requiring complete cryptographic mining, thus balancing security with user experience.
Solution Approach 2:
The proof-of-work mechanism is dynamic and adaptive. The server can adjust the difficulty and complexity of the code block assembly based on network conditions and attack patterns. The system dynamically generates code blocks with varying complexity levels, allowing the proof-of-work to scale with threat levels while maintaining acceptable performance for legitimate users under normal conditions.
3Productivity
If the server processes a large number of requests quickly, then service responsiveness is improved, but the server becomes vulnerable to resource exhaustion from malicious requests
Solution Approach 1:
The patent performs proof-of-work verification before the server processes the actual request. By requiring clients to complete the code block assembly and key generation in advance, the server ensures that only authenticated and rate-limited requests are processed. This preliminary action filters out malicious requests before they can consume server resources, protecting the server's availability while maintaining throughput for legitimate users.
Solution Approach 2:
The patent introduces an intermediary verification layer where the server issues code blocks to clients, and clients must correctly assemble and execute them to receive a validation token. This intermediary step acts as a gatekeeper between request submission and server processing. The intermediary proof-of-work mechanism verifies client authenticity and rate-limit compliance before allowing requests to reach the server, preventing resource exhaustion attacks while maintaining service responsiveness.
Data Source
AI summary
Techniques are provided for proof-of-work based on runtime compilation. Key generation code is partitioned into a set of code blocks. The key generation code generates an expected key value when compiled and executed. A shuffled set of code blocks is generated by reordering the set of code blocks. A client computing device is provided the shuffled set of code blocks and problem-solving code that, when executed at the client computing device, reconstructs the key generation code to generate a submission value by performing one or more compiling iterations. Each compiling iteration comprising reordering the shuffled set of code blocks to generate test code, and attempting to compile and execute the test code to generate the submission value. It is determined that the client computing device fully executed the problem-solving code based on the verifying the submission value.