Modular Smart Contracts for Blockchain Validation Updates

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing blockchain systems lack flexibility, particularly in updating data structures and smart contracts, which are resource-intensive and do not allow for real-time reflection of changing laws and regulations, and require developers to recode and redeploy smart contracts on all nodes.

Innovation Solution

The implementation of modular smart contracts that allow for the creation of new versions of data objects with updated attributes and validation rules, enabling real-time tracking of interactions and maintaining privacy by controlling access to attributes, and facilitating updates without redeploying smart contract code.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If smart contracts are updated by recoding and redeploying on all nodes, then the blockchain maintains consistency and security, but the process becomes resource-intensive and time-consuming

Engineering Contradiction:

Improveblockchain consistencyVSAvoidupdate time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The smart contract is divided into a reusable template and instance-specific data. The template remains immutable on the blockchain while instance data is stored off-chain or in a world state database, allowing updates without redeployment.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system transitions from static smart contracts to dynamic instances that can be updated. The template provides the structural framework while instance data can be modified over time without affecting the template's immutability.

Inventive Principle:

Principle #15Dynamics

2Adaptability or versatility

If existing data structures are updated with new attributes, then the system adapts to changing laws and regulations, but the existing attributes and their values are overwritten or lost

Engineering Contradiction:

Improveadaptability to legal changesVSAvoidattribute data loss

Core Design Contradiction:

Adaptability or versatilityVSLoss of information

Solution Approach 1:

The data structure is segmented into versioned attributes. Each attribute has a version number that tracks changes over time. When new attributes are added, existing attributes retain their values in previous versions while new versions are created.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Instead of overwriting all attributes when updating, the system applies partial updates only to the specific attributes that need changes. Existing attributes preserve their values unless explicitly modified.

Inventive Principle:

Principle #16Partial or excessive action

3Loss of information

If all attributes are made accessible to all parties, then transparency is improved, but privacy and confidentiality of party-specific information are compromised

Engineering Contradiction:

Improveinformation transparencyVSAvoidprivacy violation

Core Design Contradiction:

Loss of informationVSObject-affected harmful factors

Solution Approach 1:

Different accessibility rights are assigned to different attributes. Party-specific attributes have restricted access to their respective parties, while shared attributes are accessible to all parties. This local differentiation of quality maintains both transparency and privacy.

Inventive Principle:

Principle #3Local quality

Solution Approach 2:

Attributes are segmented into private and shared categories. The smart contract enforces access control based on this segmentation, allowing selective disclosure of information to different parties.

Inventive Principle:

Principle #1Segmentation

4Productivity

If validation rules are hard-coded in smart contracts, then execution is efficient and deterministic, but the rules cannot be updated without recoding and redeploying

Engineering Contradiction:

Improveexecution efficiencyVSAvoidvalidation rule flexibility

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

Validation rules are separated from the smart contract template. The template contains only the execution logic, while validation rules are stored as configurable parameters or metadata that can be updated independently.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Validation rules are implemented as configurable parameters rather than hard-coded logic. These parameters can be modified without changing the contract code, allowing adaptive validation behavior.

Inventive Principle:

Principle #35Parameter changes

Data Source

PatentUS11748752B2Modular, configurable smart contracts for blockchain transaction processing validations

Publication Date: 2023.09.05 KPMG LLP

AI summary

The invention relates to systems and methods for providing modular and configurable smart contracts for blockchain applications. The smart contracts may be utilized to retain all transaction attribute values in a world state database of the blockchain-implemented ledger. The systems and methods can further provide for dynamically configurable validation metadata and validation rules for transaction attributes recorded on a blockchain transaction log. The validation metadata and validation rules corresponding to the transaction attributes can be dynamically updated and applied to the transaction attributes to validate or invalidate a transaction.