Smart Contract Language for Static Gas Cost Estimation

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

The Ethereum blockchain model is Turing complete, making it impossible to determine the Gas cost required to complete a smart contract before its execution, leading to uncertainties in transaction fees.

Innovation Solution

A smart contracting language that enables static analysis to estimate properties such as runtime operations, data writes, and function calls before execution, allowing for accurate upper-bound estimates of transaction costs by limiting data types and recursion, and using a non-compiled high-level language like Lisp.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If Turing complete smart contracts are used, then programming capability and flexibility are improved, but transaction cost prediction becomes impossible

Engineering Contradiction:

Improveprogramming capabilityVSAvoidtransaction cost prediction

Core Design Contradiction:

Adaptability or versatilityVSMeasurement precision

Solution Approach 1:

The patent changes the fundamental parameter of the smart contract language from Turing complete to non-Turing complete (Lisp-based with limited recursion). This parameter change enables static analysis of runtime operations, data writes, and function calls, thereby achieving precise transaction cost prediction while maintaining sufficient programming capability for practical applications.

Inventive Principle:

Principle #35Parameter changes

2Measurement precision

If static analysis is enabled for cost estimation, then transaction cost prediction accuracy is improved, but language flexibility and expressiveness are reduced

Engineering Contradiction:

Improvecost estimation accuracyVSAvoidlanguage flexibility

Core Design Contradiction:

Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The patent adopts a Lisp-based language with controlled recursion depth as the smart contract language. This parameter change enables the system to perform static analysis and provide accurate cost estimates while maintaining adequate language flexibility for real-world smart contract development through Lisp's powerful data structures and functional programming capabilities.

Inventive Principle:

Principle #35Parameter changes

3Ease of repair

If uncompiled source code is stored on blockchain, then debugging and recovery capability are improved, but storage requirements and system complexity increase

Engineering Contradiction:

Improvedebugging capabilityVSAvoidsystem complexity

Core Design Contradiction:

Ease of repairVSDevice complexity

Solution Approach 1:

The patent stores uncompiled Lisp source code directly on the blockchain alongside the compiled bytecode. This copying approach enables full debugging and recovery capabilities by preserving the original source, while the system manages complexity through the inherent simplicity of Lisp's interpreted execution model and the blockchain's native storage capabilities.

Inventive Principle:

Principle #26Copying

Data Source

PatentUS11513815B1Defining data storage within smart contracts

Publication Date: 2022.11.29 HIRO SYST PBC

AI summary

The source code of a smart contract defines a schema for a data map with a map name, a key, and a value, and when executing the smart contract, a virtual machine calls an function that inserts the data map into a data store as defined by the data map schema, the inserted data map comprising the map name defined in the smart contract source code, a key value defined in a transaction for the key, and a value from the transaction for the value.