Proof of Majority Block Consensus Method for Blockchain

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional blockchain technologies face issues with decentralization, democratization, high processing power requirements, high network energy consumption, and the inability to guarantee all transactions will be processed due to flaws in existing block consensus techniques.

Innovation Solution

A proof of majority block consensus method that promotes decentralized and democratic blockchain operations by implementing a mutually enforced collaboration between nodes, using network gossiping protocols to propagate transactions, and ensuring that blocks are generated based on the majority hash consensus.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If proof of work block consensus is used, then transaction authentication is provided, but massive processing power and network energy consumption are required

Engineering Contradiction:
Improvetransaction authenticationVSAvoidprocessing power and network energy consumption
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent segments the block generation process into two distinct phases: (1) collaborative transaction gathering phase where nodes work together to collect and validate transactions, and (2) competitive block creation phase where nodes compete to generate the winning block. This segmentation allows the energy-intensive proof-of-work to be performed only once per block by the winning node, while other nodes contribute computational effort to transaction validation and propagation, thereby reducing overall network energy consumption while maintaining security.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent inverts the traditional proof-of-work model by having nodes collaborate rather than compete during the transaction gathering phase. Instead of all nodes independently performing proof-of-work attempts, nodes work together to build a pool of validated transactions, then compete only to select which transactions to include and in what order. This inversion transforms the competitive zero-sum game into a collaborative effort followed by a controlled competition, significantly reducing redundant computational work.

Inventive Principle:
Principle #13The other way round (Inversion)

2Productivity

If proof of work block consensus is used, then block generation is achieved, but decentralization and democratization are compromised

Engineering Contradiction:
Improveblock generationVSAvoiddecentralization and democratization
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent segments node participation into different roles: collaborative nodes that gather and validate transactions (accessible to any node with minimal resources) and competitive nodes that attempt to create blocks (requiring higher computational power). This segmentation allows widespread decentralized participation in transaction validation while maintaining a competitive block creation mechanism, thereby preserving both decentralization and productivity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a collaborative transaction pool as an intermediary mechanism between transaction submission and block creation. This intermediary pool serves as a shared resource that all nodes can contribute to and access, leveling the playing field for participation while the subsequent competitive phase determines block creation. The intermediary structure prevents direct resource competition from immediately determining network influence, thereby supporting democratization.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Speed

If competitive block generation is used, then block creation speed is improved, but transaction processing completeness is compromised

Engineering Contradiction:
Improveblock creation speedVSAvoidtransaction processing completeness
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The patent implements preliminary collaborative action where nodes gather, validate, and propagate transactions into a shared pool before the competitive block creation phase begins. This preliminary action ensures that transactions are pre-validated and propagated across the network, so that when the competitive phase determines the winning block, the transactions are already verified and ready for inclusion. This eliminates the risk of losing unprocessed transactions due to competitive timing issues.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent maintains continuous useful action by having nodes simultaneously engage in transaction validation and propagation throughout the collaborative phase, rather than pausing while waiting for block creation. Nodes continuously contribute to the transaction pool and validate incoming transactions, ensuring that the processing pipeline remains active and complete throughout the entire block generation cycle, thereby maintaining both speed and reliability.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS20250150280A1Proof Of Majority Block Consensus Method For Generating And Uploading A Block To A Blockchain
Publication Date: 2025.05.08 BRYT LLC
  • US20250150280A1 patent drawing
  • US20250150280A1 patent drawing
  • US20250150280A1 patent drawing

AI summary

Embodiments disclosed herein describe a proof of majority block consensus method based upon a mutually enforced collaboration between the nodes. A node may maintain a random subset of connected peer nodes, refreshed at every epoch through network gossiping protocols. The node may propagate received transactions to selected peers in the random subset. The node may generate a transaction ballot from received transactions and iteratively update the transaction ballot by mutual exchanges with other nodes until the network converges. The node may generate a block- and a hash thereof-based upon its understanding of the transaction ballot. The node may also receive hashes from other connected nodes and identify a hash generated by the majority of peer nodes. If the node determines that its own hash is the one generated by the majority of peer nodes, the node may update its local copy of the blockchain by appending its block.