Blockchain Locking Scripts for Constrained Unlocking Bytecode Injection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current blockchain technologies, such as Bitcoin's Script, restrict complex flow control functionality and do not support loops, leading to limitations in implementing secure and flexible smart contracts, particularly in managing undetermined data and ensuring data integrity during transactions.

Innovation Solution

The implementation of self-referencing and self-replicating blockchain transaction locking scripts that allow secure injection of undetermined data from determined or undetermined sources, using cryptographic techniques to validate transactions without verifying the entity's access to secret information, and enabling parameterized smart contracts that enforce constraints through locking scripts.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If blockchain transactions use traditional scripting languages (e.g., Bitcoin's Script), then transaction validation is secure and immutable, but complex flow control functionality and loops are restricted

Engineering Contradiction:
Improvecomplex flow control functionalityVSAvoidscripting language capabilities
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a locking script as an intermediary component that mediates between the transaction input and output. This locking script contains the complex flow control logic and conditions, while the unlocking script provides a simplified interface for validation. The locking script acts as a mediator that enables sophisticated smart contract functionality without requiring the underlying blockchain scripting language to support complex control structures directly.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the transaction validation logic into separate components: locking scripts that contain the complex business logic and flow control, and unlocking scripts that provide the verification mechanism. This segmentation allows complex functionality to be encapsulated in the locking script while maintaining the simplicity and security of the validation process through the unlocking script.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If blockchain transactions allow access to undetermined data, then smart contract flexibility is improved, but data integrity and security constraints become difficult to enforce

Engineering Contradiction:
Improvesmart contract flexibilityVSAvoiddata integrity
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent applies preliminary action by requiring that data integrity constraints be predefined and encoded in the locking script before the transaction is executed. The locking script contains predetermined conditions and validation rules that must be satisfied. This allows the system to handle undetermined data flexibly while ensuring that integrity constraints are enforced through pre-established rules.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements feedback mechanisms through the locking and unlocking script validation process. The locking script provides feedback on what constraints must be satisfied, and the unlocking script provides feedback on whether the provided data meets those constraints. This feedback loop ensures data integrity while allowing flexibility in how undetermined data is handled.

Inventive Principle:
Principle #23Feedback

3Reliability

If locking scripts constrain all transaction fields, then data security is improved, but the ability to handle undetermined data from undetermined sources is reduced

Engineering Contradiction:
Improvedata securityVSAvoidhandling undetermined data
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent applies local quality by allowing different levels of constraint application to different parts of the transaction data. The locking script can specify which fields require strict validation and which fields can accept undetermined data. This selective constraint approach maintains security for critical data while allowing flexibility for undetermined data from undetermined sources.

Inventive Principle:
Principle #3Local quality

4Productivity

If blockchain transactions use simple validation scripts, then transaction processing is fast and simple, but smart contract functionality is limited

Engineering Contradiction:
Improvetransaction processing speedVSAvoidsmart contract functionality
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent extracts complex smart contract logic from the core transaction validation process and places it in locking scripts. This extraction allows the core blockchain validation to remain simple and fast, while sophisticated smart contract functionality is implemented in the separable locking script component. The unlocking script provides a streamlined validation interface that maintains processing efficiency.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentEP3631727B1Constraining injection of unlocking transaction bytecode
Publication Date: 2025.07.09 NCHAIN LICENSING AG
  • EP3631727B1 patent drawingFigure 1
  • EP3631727B1 patent drawingFigure 2
  • EP3631727B1 patent drawingFigure 3

AI summary

The invention relates to distributed ledge technologies such as consensus-based blockchains. The methods and systems of the present disclosure are provided for causing an injection of a serialized set of field values of an unlocking transaction into a locking script are described. The invention is implemented using a blockchain network, which may for example be a Bitcoin blockchain. A first transaction to validate is received at a node in the blockchain network. The first transaction includes a first script that includes a set of field values of the first transaction and, as a result of being executed, causes the node to obtain a set of field values. A second transaction is obtained, with the second transaction having been validated. The second transaction includes a second script that, as a result of being executed, causes the node to generate a signature based at least in part on the set of field values supplied as a result of execution of the first script. The first transaction is validated by execution of the first script and the second script.