HMP-0005_06_03

Источник: HMP-0005_06_03.md

HyperCortex Mesh Protocol (HMP 5.0.8) - модульное представление

6. Core protocols

Смотреть 6. Core protocols - общая часть

6.3 Fortytwo Consensus Protocol (Pairwise Collective Reasoning)

Based on the study: Agata Grzybowska, Wojciech Bożejewicz, Timothy Nguyen, et al. “Fortytwo: Collective Reasoning with Paired Comparisons in Decentralized AI Swarms”, 2025. (arXiv:2510.24801)

6.3.1 Overview

The Fortytwo Consensus Protocol implements a decentralized collective-reasoning mechanism in HyperCortex Mesh using pairwise comparisons, iterative rounds, and reputation-weighted aggregation.

Unlike the Mesh Consensus Protocol (CogConsensus), Fortytwo is not intended to produce a binary agreement. Its goal is to select the best solution among many alternatives using a distributed multi-stage evaluation process.

Fortytwo enables:

  • higher accuracy of collective decisions,
  • resistance to Sybil attacks and malicious scoring,
  • independent evaluations from many judges (agents),
  • aggregation of results into a multi-round tree structure,
  • transparent reasoning via short CoT chains.

The protocol is fully compatible with HMP container architecture and can operate as an independent mechanism for collective choice.

6.3.2 Protocol Objectives

Fortytwo is designed for:

  1. Collecting candidate solutions for a given task.
  2. Constructing structured pairwise comparisons among participants.
  3. Multi-round elimination of candidates.
  4. Independent evaluation by distributed judges.
  5. Producing a consistent global result based on aggregated pairwise data.
  6. Ensuring transparency and verifiability of reasoning for each judge.
  7. Building a consensus tree stored in the DHT.

6.3.3 Roles in the Protocol

  • Producers — agents submitting candidate solutions.
  • Judges — agents performing pairwise evaluations.
  • Partitioners — agents generating round partitions.
  • Aggregators — agents publishing round results and the final result.

Roles are not fixed and require no prior declaration; any agent may assume any role by publishing the corresponding container.

6.3.4 Container Types

class purpose
fortytwo_round round partition
fortytwo_evaluation pairwise comparison
fortytwo_round_result round result
fortytwo_final_result final aggregated result
Container for solution submission

Used to submit answers to a task.

Although workflow_entry (defined in the §6.4 Goal Management Protocol, GMP) is referenced here as the default solution container, the Fortytwo method is applicable to any homogeneous set of candidate containers.

Container fortytwo_round (round partition)

Defines the structure of pairwise comparisons for the current round.

Simplified structure:

{
  "head": {
    "class": "fortytwo_round"
  },
  "payload": {
    "round": 0,
    "answers": [
      "did:hmp:container:abc001", "did:hmp:container:abc002",
      "did:hmp:container:abc003", "did:hmp:container:abc004",
      "did:hmp:container:abc005", "did:hmp:container:abc006",
      "did:hmp:container:abc007"
    ],
    "blocks": {
      "block1": ["did:hmp:container:abc001", "did:hmp:container:abc002"],
      "block2": ["did:hmp:container:abc003", "did:hmp:container:abc004"],
      "block3": ["did:hmp:container:abc005", "did:hmp:container:abc006"],
      "block4": ["did:hmp:container:abc007"]
    }
  }
}

Any agent may publish such a container — the protocol allows multiple independent partitions.

Container fortytwo_evaluation (pairwise evaluation)

A judge compares two solutions and selects a winner.

{
  "head": {
    "class": "fortytwo_evaluation"
  },
  "payload": {
    "comparison": {
      "pair": ["did:hmp:container:abc001", "did:hmp:container:abc002"],
      "winner": "did:hmp:container:abc001",
      "reasoning": "Short reasoning (50–100 tokens)"
    },
    "round": 0,
    "block": "block1"
  }
}

These containers form the distributed pairwise comparison matrix.

Container fortytwo_round_result (round result)

Stores the winners of a round.

{
  "head": {
    "class": "fortytwo_round_result"
  },
  "payload": {
    "round": 0,
    "winners": [
      "did:hmp:container:abc001",
      "did:hmp:container:abc003",
      "did:hmp:container:abc005",
      "did:hmp:container:abc007"
    ],
    "evaluations_used": [
      "did:hmp:container:abf004",
      "did:hmp:container:adc003",
      "did:hmp:container:aba001"
    ]
  }
}
Container fortytwo_final_result (final result)

Contains:

  • the final winner,
  • all round results,
  • references to all partitions and evaluations.
{
  "head": {
    "class": "fortytwo_final_result"
  },
  "payload": {
    "winner": "did:hmp:container:abc002",
    "rounds": [
      "did:hmp:container:abf001",
      "did:hmp:container:abf002",
      "did:hmp:container:abf003"
    ],
    "method": "pairwise_collective_reasoning",
    "participants": 27
  }
}

In all Fortytwo containers, the related block establishes the DAG of dependencies.

  • related.in_reply_to specifies the primary parent for this step.
  • related.depends_on may contain all containers referenced during the action, including both explicit payload entries and additional dependencies chosen by the agent.

Specific recommendations:

  • fortytwo_round

    • in_reply_to: a task container (first round) or the previous fortytwo_round.
    • depends_on: submitted solutions (workflow_entry) and any containers used to construct the partition.

  • fortytwo_evaluation

    • in_reply_to: the corresponding fortytwo_round.
    • depends_on: both compared solutions and any extra reasoning dependencies.

  • fortytwo_round_result

    • in_reply_to: the corresponding fortytwo_round.
    • depends_on: round winners and all evaluation containers used in aggregation.

  • fortytwo_final_result

    • in_reply_to: the task container.
    • depends_on: the final winner and all fortytwo_round_result containers involved.

6.3.5 Protocol Algorithm

Step 1 — Task publication A task container is created.

Step 2 — Collecting all solutions Agents publish workflow_entry containers.

Step 3 — Round partitioning Any agent may publish a fortytwo_round defining pairwise comparison blocks:

  • pairs of candidates,
  • single items automatically advancing.

Step 4 — Pairwise evaluations Other agents perform comparisons according to the partition. Each pair produces a fortytwo_evaluation container.

Step 5 — Round result An aggregator publishes a fortytwo_round_result containing:

  • winners of all blocks,
  • references to evaluation containers.

Step 6 — Next round If more than one winner remains:

  • a new partition is created,
  • new evaluations are performed.

Step 7 — Final result When only one candidate remains, a fortytwo_final_result is published.

This container, like any other, may be published by multiple agents, with optional argumentation via the evaluations block.

6.3.6 Tree-like consensus structure

Protocol outputs form a DAG:

(task)
   ├─ workflow_entry 1
   ├─ workflow_entry 2
   ├─ workflow_entry 3
   ├─ workflow_entry 4
   ├─ fortytwo_round 0
   |     ├─ fortytwo_evaluation 0.1
   |     ├─ fortytwo_evaluation 0.2
   |     ├─ fortytwo_evaluation 0.3
   |     ├─ fortytwo_round_result 0
   |     └─ fortytwo_round 1
   |           ├─ fortytwo_evaluation 1.1
   |           ├─ fortytwo_evaluation 1.2
   |           ├─ fortytwo_evaluation 1.3
   |           └─ fortytwo_round_result 1
   |                 ├─ ...
   └─ fortytwo_final_result

Each round reduces the number of candidates until only one remains.

This ensures:

  • transparency,
  • verifiability,
  • easy replication in the DHT.

6.3.7 Integration with CogConsensus

Fortytwo:

  • does not replace CogConsensus,
  • but provides a mechanism for selecting the best answer.

CogConsensus remains the higher-level agreement layer, responsible for:

  • validating final results,
  • verifying round correctness,
  • coordinating task flow.

6.3.8 Robustness and Security

Fortytwo is resilient to:

  • Sybil attacks, since every judge must provide capability-proof,
  • malicious evaluations, due to distributed pairwise data and independent aggregators,
  • partial failures, because rounds can be re-aggregated by any agent.

6.3.9 Replication and Storage

All Fortytwo containers:

  • are published into the DHT,
  • maintain stable reference structure,
  • may be aggregated independently by any agent.

6.3.10 Applications

Fortytwo is suitable for:

  • evaluating reasoning chains,
  • selecting the best argument or proof,
  • solving mathematical problems,
  • choosing optimal code solutions,
  • scientific analysis,
  • complex multi-step decision-making.

Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Habr_Distributed-Cognition

Источник: Habr_Distributed-Cognition.md От OpenCog Hyperon до HyperCortex Mesh Protocol: как устроены децентрализованные когнитивные системы Альтернатива централизованным ИИ: гиперграфы, mesh-взаимодействие и совместное мышление агентов Зачем нужны децентрализованные когнитивные системы? Сегодня интеллектуальные системы чаще всего выглядят как один большой модуль в облаке — LLM, с которым мы общаемся через API или WEB-интерфейс. Но если мы хотим построить действительно автономную интеллектуальную систему (или AGI), то нам потребуется: Смысловая память, а не токены Способность планировать и распределять задачи Этические оценки перед действием И главное: связь с другими агентами, чтобы обмениваться знаниями, достигать согласия и общего понимания. Два проекта, которые решают эти задачи с разных сторон: OpenCog Hyperon (фокус на внутреннюю когницию и гиперграфы) HyperCortex Mesh Protocol (HMP) (сетевой уровень: обмен целями, знаниями, смыслами, совмест...
Read more »

HMP-0005

Источник: HMP-0005.md HyperCortex Mesh Protocol (HMP) Version: 5.0.8 Document ID: HMP-0005 Status: Stable Category: Core Specification Release Date: March 2026 Canonical Repository: https://github.com/kagvi13/HMP Authors: Глеб (GitHub: @kagvi13), Максим Хотинский (Maksim Khotinsky); AI-assisted by ChatGPT (OpenAI) Supersedes: - HMP-0004 v4.1 Summary: HMP v5.0 unifies the cognitive, container, and network layers into a single architecture in which autonomous agents interact through verifiable data containers, using decentralized propagation and semantic search. This version formalizes the container format for the first time, integrates a DHT as the foundational network layer, and introduces a unified scheme for signatures, proofs, and consensus. Abstract The HyperCortex Mesh Protocol (HMP) defines a distributed cognitive framework where autonomous agents cooperate to create, exchange, and align knowledge without centralized control or autho...
Read more »

CHANGELOG

Источник: CHANGELOG.md HyperCortex Mesh Protocol — Changelog HMP-0005 (May 2026) — Core Specification v5.0.8 Encryption and payload integrity clarifications: Clarified head.payload_hash semantics: the hash is computed over the final serialized payload representation (including optional compression and encryption). Unified payload_hash wording across Sections 3.3 and 3.9. Refined hybrid-encryption processing terminology: clarified usage of symmetric session keys and recipient encryption envelopes. Clarified that key_recipient contains an encrypted symmetric session key and may be transmitted openly alongside the container. Improved wording for encrypted container verification and store-and-forward propagation behavior. No semantic changes to the protocol model. No wire-format changes. Fully backward-compatible within the 5.0.x series. HMP-0005 (May 2026) — Core Specification v5.0.7 Extended representations for referenced-by.link...
Read more »