Merkle Tree Smart Contract Encoding
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The current scripting language limitations in blockchain technology restrict the creation of complex smart contracts due to script size constraints and the linear scaling of script requirements with the number of dependencies, leading to a frustratingly low capacity for encoding conditions.
Innovation Solution
The use of Merkle trees to encode smart contracts, where a trusted third party generates a hash tree based on contract conditions, with only the root hash and secret hash keys known to the trusted party, allowing efficient encoding and execution of smart contracts with minimal script requirements.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a stack-based scripting language is used for transactions, then transactions can be executed on the blockchain, but the script size is limited and cannot encode complex contracts with many dependencies
Solution Approach 1:
The patent segments the contract encoding into two parts: a Merkle tree structure that organizes condition data, and a minimal script that only needs to reference the root hash. This segmentation allows complex contracts with many dependencies to be encoded efficiently, as the script size does not scale linearly with the number of conditions.
Solution Approach 2:
The patent introduces a Merkle tree as an intermediary structure between the contract conditions and the transaction script. The Merkle tree root hash serves as a mediator that encapsulates all contract conditions, allowing the script to reference the entire contract state through a single hash value rather than including all condition details directly in the script.
2Adaptability or versatility
If more conditions are included in the contract, then the contract becomes more comprehensive, but the script size increases linearly with the number of dependencies
Solution Approach 1:
The patent merges all contract conditions into a single Merkle tree structure, where multiple conditions are combined through hierarchical hashing. This merging allows the script to reference all conditions through the root hash, reducing the script length from linear scaling to constant size regardless of the number of conditions.
Solution Approach 2:
The patent transitions from a linear representation of conditions to a hierarchical tree structure. By organizing conditions in multiple dimensions (tree levels), the system can encode many more conditions without increasing script length proportionally, as the script only needs to access the root of the tree rather than list all individual conditions.
3Extent of automation
If contract conditions are encoded in the transaction, then the contract can be executed on-chain, but sensitive data is revealed publicly on the blockchain
Solution Approach 1:
The patent extracts sensitive contract condition data from the transaction script and stores it in the Merkle tree structure. Only the root hash (a cryptographic summary) is included in the transaction, while the actual condition data remains hidden in the tree structure, accessible only to parties with the appropriate access keys.
Solution Approach 2:
The patent changes the parameter representation from raw condition data to cryptographic hashes. By transforming condition data into hash values and organizing them in a Merkle tree, the system maintains the ability to execute contracts while protecting sensitive information, as the hashed representation preserves verification capability without exposing the original data.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A computer-implemented method of encoding a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract being for transferring an amount of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by a trusted third party and comprising: in response to determining that a condition of the contract linked to the second party has been fulfilled, providing the second party with a signature of the trusted third party for inclusion in a transaction of the blockchain, wherein the signature signs a data element representing the fulfilled condition.