Blockchain Contract Encoding With Merkle Trees for Complex Conditions

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The current scripting language limitations in blockchain technology restrict the creation of complex smart contracts, particularly due to the linear scaling of script size with the number of dependencies, leading to a frustratingly low capacity for encoding conditions in transactions.

Innovation Solution

The use of a hash tree, specifically a Merkle tree, to encode smart contract conditions, where only a root hash is required, reducing the script size and computational requirements, and ensuring secure execution by involving a trusted third party to generate and authenticate conditions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a stack-based scripting language is used to encode smart contract conditions, then the contract can be executed on the blockchain, but the script size scales linearly with the number of dependencies, limiting the complexity of encodable contracts

Engineering Contradiction:
Improvecontract complexity capacityVSAvoidscript size
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the contract conditions into a tree structure where leaf nodes represent individual conditions and internal nodes represent logical operations. This hierarchical segmentation allows the contract to be encoded more efficiently than linear scripting, as the tree structure compresses the representation of complex conditional logic.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent transitions from one-dimensional linear scripting to a two-dimensional tree structure. By organizing conditions in a hierarchical tree rather than a sequential list, the encoding capacity increases significantly while maintaining executable form, effectively adding a dimensional aspect to the contract representation.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Adaptability or versatility

If more conditions are included in the smart contract, then the contract becomes more comprehensive, but the computational overhead increases

Engineering Contradiction:
Improvenumber of conditionsVSAvoidcomputational overhead
Core Design Contradiction:
Adaptability or versatilityVSUse of energy by moving object

Solution Approach 1:

The patent performs preliminary computation by generating a Merkle root hash of all contract conditions before the contract is executed on the blockchain. This pre-computation allows the blockchain to verify the integrity of conditions efficiently during execution, reducing the computational overhead during actual contract fulfillment since the heavy hashing work was already done beforehand.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent replaces the mechanical process of verifying each condition individually during contract execution with a cryptographic hash-based verification system. Instead of computationally checking each condition's validity during execution, the system uses Merkle tree hashes to provide efficient proof of condition inclusion, substituting cryptographic verification for computational verification.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

3Ease of operation

If contract conditions are encoded in the transaction, then the contract can be executed, but sensitive data is exposed in the public blockchain

Engineering Contradiction:
Improvecontract executionVSAvoiddata privacy
Core Design Contradiction:
Ease of operationVSLoss of information

Solution Approach 1:

The patent extracts sensitive condition data from the public transaction record and replaces it with cryptographic hash representations. The actual condition values are kept off-chain or in private storage, while only their hash proofs are included in the blockchain transaction, allowing verification without exposing the underlying sensitive information.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces cryptographic hash functions as an intermediary between the sensitive condition data and the public blockchain. The hash function transforms private data into a public representation that can be verified on-chain without revealing the original data, acting as a mediator that preserves both executability and privacy.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS20260012369A1Digital contracts using blockchain transactions
Publication Date: 2026.01.08 NCHAIN LICENSING AG
  • US20260012369A1 patent drawing
  • US20260012369A1 patent drawing
  • US20260012369A1 patent drawing

AI summary

A computer-implemented method of encoding a digital contract between first and second parties of a blockchain network, the digital contract being for transferring an amount of a digital asset from the first to the second party based on a condition being fulfilled; the method comprising: obtaining a plurality of data elements, each representing a different contract condition, wherein at least one of the conditions is linked to the second party; generating a hash tree based on the data elements, wherein the hash tree comprises: i) first leaf hashes generated by hashing a respective data element, and second leaf hashes comprising at least one hash key generated by hashing a secret value known only to the trusted third party, ii) internal hashes, and iii) a root hash; and making the root hash available to the first party for inclusion in a transaction of the blockchain.