c/ietf-draft-analyzer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
42b4546ded7d8765e20bb7afdb94b72fd614f7e7
ietf-draft-analyzer/data/reports/generated-drafts/draft-gap-37-multi-agent-consensus-protocols.txt
Christian Nennemann e247bfef8f Run pipeline, write Post 08, commit untracked files 
Pipeline:
- Extract ideas for 38 new drafts → 462 ideas total
- Convergence analysis: 132 cross-org convergent ideas (33% rate)
- Fetch authors for 102 drafts → 709 authors (up from 403)
- Refresh gap analysis: 12 gaps across full 474-draft corpus
- Update verified counts with new totals

Post 08:
- Complete rewrite of "Agents Building the Agent Analysis" (2,953 words)
- Covers 3 phases: writing team → review cycle → fix cycle
- Meta-irony table mapping team coordination to IETF gap names
- Specific examples from dev journal (SQL injection, consent conflation, ideas mismatch)

Untracked files committed:
- scripts/: backfill-wg-names, classify-unrated, compare-classifiers, download-relevant-text, run-webui
- src/ietf_analyzer/classifier.py: two-stage Ollama classifier
- src/webui/: analytics (GDPR-compliant), auth, obsidian_export
- tests/test_obsidian_export.py (10 tests)
- data/reports/: wg-analysis, generated draft for gap #37

Housekeeping:
- .gitignore: exclude LaTeX artifacts, stale DBs, analytics.db

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-08 15:31:30 +01:00

657 lines
36 KiB
Plaintext
Raw Blame History

Internet-Draft AI/Agent WG
Intended status: standards-track March 2026
Expires: September 08, 2026
Multi-Agent Consensus Protocol (MACP) for Distributed AI Agent Coordination
draft-ai-consensus-protocol-00
Abstract
This document defines the Multi-Agent Consensus Protocol (MACP), a
standardized framework for enabling multiple AI agents to reach
consensus on shared decisions and resolve conflicting objectives
in distributed environments. MACP addresses critical coordination
challenges in autonomous systems where agents must collaborate on
resource allocation, policy enforcement, and decision-making
across organizational and domain boundaries. The protocol
incorporates Byzantine fault tolerance mechanisms, cryptographic
verification, and hierarchical consensus structures to ensure
reliable agreement even in the presence of malicious or
malfunctioning agents. MACP defines message formats, consensus
algorithms, conflict resolution procedures, and integration
patterns with existing agent-to-agent communication protocols. The
protocol supports various consensus models including proof-of-
authority, weighted voting, and reputation-based systems, enabling
deployment across diverse use cases from IoT device coordination
to enterprise AI system orchestration. This specification aims to
reduce fragmentation in multi-agent systems and provide a
foundation for interoperable autonomous agent coordination at
scale.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is intended to have standards-track status.
Distribution of this memo is unlimited.
Table of Contents
1. Introduction ................................................ 3
2. Terminology ................................................. 4
3. Problem Statement ........................................... 5
4. MACP Architecture and Core Components ....................... 6
5. Consensus Algorithms and Message Formats .................... 7
6. Conflict Resolution and Decision Binding .................... 8
7. Integration with Existing Agent Protocols ................... 9
8. Security Considerations ..................................... 10
9. IANA Considerations ......................................... 11
1. Introduction
The proliferation of autonomous AI agents across distributed
computing environments has created an urgent need for standardized
consensus mechanisms that enable coordinated decision-making
without centralized control. As organizations deploy increasing
numbers of intelligent agents for tasks ranging from resource
allocation and policy enforcement to complex multi-party
negotiations, the lack of interoperable consensus protocols has
resulted in fragmented implementations that cannot effectively
coordinate across organizational and domain boundaries. Current
agent-to-agent communication protocols, while addressing basic
message exchange and authentication, provide insufficient
mechanisms for achieving reliable agreement among multiple agents
with potentially conflicting objectives or incomplete information.
Existing consensus approaches in multi-agent systems typically
rely on proprietary coordination mechanisms or adapt consensus
algorithms designed for blockchain and distributed database
applications without addressing the unique requirements of AI
agent coordination. These limitations become particularly acute in
scenarios involving Byzantine fault tolerance, where agents may
exhibit malicious behavior, experience partial failures, or
operate under adversarial conditions. The heterogeneous nature of
AI agent implementations, combined with varying trust
relationships and organizational policies, further complicates the
development of effective consensus mechanisms that can operate
reliably at scale.
The Multi-Agent Consensus Protocol (MACP) addresses these
challenges by providing a standardized framework specifically
designed for AI agent coordination that incorporates proven
consensus algorithms while addressing the unique requirements of
autonomous agent systems. MACP supports multiple consensus models
including proof-of-authority, weighted voting based on agent
reputation or capabilities, and hierarchical consensus structures
that reflect organizational boundaries and trust relationships.
The protocol integrates cryptographic verification mechanisms and
Byzantine fault tolerance to ensure reliable consensus achievement
even in the presence of malicious or malfunctioning agents, while
maintaining compatibility with existing agent communication and
attestation frameworks.
The scope of MACP encompasses the definition of consensus
algorithms optimized for AI agent coordination, standardized
message formats for proposal submission and voting processes,
conflict resolution mechanisms for handling competing objectives,
and integration patterns with existing agent-to-agent protocols.
This specification aims to reduce the current fragmentation in
multi-agent coordination approaches by providing a foundation for
interoperable consensus mechanisms that can scale from small IoT
device clusters to enterprise-wide AI system orchestration. By
establishing common protocols for multi-agent consensus, MACP
enables the development of more robust and coordinated autonomous
systems while maintaining the flexibility required for diverse
deployment scenarios and organizational requirements.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
This section establishes terminology specific to multi-agent
consensus operations and distributed AI agent coordination. These
definitions build upon established concepts from distributed
systems literature while introducing terminology specific to
autonomous agent environments. Where applicable, references are
made to related terminology from existing agent communication
protocols such as those defined in [RFC8600] and distributed
consensus literature.
A "consensus agent" is an autonomous AI entity capable of
participating in distributed decision-making processes by
submitting proposals, evaluating options, and committing to
agreed-upon outcomes. Consensus agents MUST maintain state
consistency with other participants and possess cryptographic
capabilities for message authentication and verification. An
"observer agent" is a non-participating entity that monitors
consensus processes without voting rights or decision authority.
A "coordination domain" defines the scope and boundaries within
which a group of agents operate under shared governance rules and
consensus mechanisms. Each coordination domain establishes its own
policies for membership, voting weights, and decision authority. A
"decision quorum" represents the minimum number or weight
threshold of participating agents required to reach a valid
consensus decision within a coordination domain, expressed either
as an absolute count or percentage of eligible participants.
"Byzantine Fault Tolerance" (BFT) refers to the system's ability
to achieve consensus despite the presence of agents that may
exhibit arbitrary failures, including malicious behavior, message
corruption, or incorrect state reporting. MACP implementations
SHOULD support Byzantine fault tolerance for up to one-third of
participating agents within any coordination domain. "Practical
Byzantine Fault Tolerance" (pBFT) describes optimized algorithms
that achieve Byzantine fault tolerance with reduced message
complexity and improved performance characteristics.
"Conflict resolution" encompasses the mechanisms and procedures
used to address competing proposals, resolve deadlocks, and handle
situations where multiple valid decisions could be reached. This
includes tie-breaking algorithms, priority-based selection, and
escalation procedures to higher-level coordination domains.
"Decision binding" refers to the enforcement mechanisms that
ensure participating agents comply with consensus outcomes and
maintain consistency with agreed-upon decisions across the
coordination domain.
3. Problem Statement
The proliferation of autonomous AI agents across distributed
systems has created an urgent need for standardized consensus
mechanisms that can coordinate decision-making without centralized
control. Current multi-agent deployments frequently encounter
scenarios where agents must collectively agree on resource
allocation, policy enforcement, task scheduling, or strategic
decisions that affect multiple stakeholders. However, existing
agent-to-agent communication protocols such as FIPA-ACL and
emerging frameworks focus primarily on message exchange and basic
coordination primitives, lacking robust consensus mechanisms
necessary for reliable distributed decision-making. This gap
becomes particularly problematic in cross-organizational
deployments where agents operate under different governance
models, trust assumptions, and operational constraints.
Network partitions and communication failures present fundamental
challenges to consensus achievement in distributed agent
environments. Unlike traditional distributed systems where nodes
typically operate within controlled network environments, AI
agents often function across heterogeneous networks with varying
reliability characteristics, from edge computing environments to
cloud infrastructure spanning multiple providers. Agents may
become temporarily or permanently unreachable, creating scenarios
where consensus decisions must proceed with incomplete information
or be safely aborted to prevent system-wide inconsistencies.
Current agent protocols provide insufficient guidance for handling
these partition scenarios, often resulting in ad-hoc
implementations that cannot guarantee safety properties or
liveness guarantees across different deployment contexts.
Conflicting objectives among participating agents introduce
additional complexity beyond traditional distributed consensus
problems. AI agents frequently operate with competing utility
functions, resource constraints, and optimization targets that may
not align with collective decision requirements. For example, in a
multi-cloud resource allocation scenario, individual agents may
prioritize cost minimization for their respective organizations
while the collective decision requires balancing performance,
security, and availability across all participants. Existing
consensus algorithms assume participants share common objectives
or can reduce decisions to simple binary choices, failing to
address the multi-dimensional optimization problems inherent in AI
agent coordination.
The presence of malicious or Byzantine actors poses significant
threats to consensus integrity in open multi-agent environments.
Unlike closed distributed systems where all participants operate
under unified security models, AI agents may need to establish
consensus across organizational boundaries where some participants
cannot be fully trusted. Malicious agents may attempt to
manipulate consensus outcomes through strategic voting, false
information injection, or coordination attacks designed to prevent
legitimate consensus achievement. Furthermore, compromised or
malfunctioning agents may exhibit Byzantine behavior without
malicious intent, requiring consensus mechanisms that can tolerate
arbitrary failures while maintaining decision quality and system
progress.
Current limitations in existing agent-to-agent protocols create
additional barriers to reliable consensus implementation. Most
protocols focus on peer-to-peer communication abstractions without
addressing the coordination complexity required for multi-party
decision-making. Authentication and authorization mechanisms are
typically designed for bilateral interactions rather than group
consensus scenarios, lacking support for quorum-based verification
or reputation systems that could improve consensus security.
Additionally, existing protocols provide limited support for
hierarchical consensus structures or delegation mechanisms that
could enable scalable decision-making in large agent populations,
forcing implementations toward flat consensus models that may not
perform well beyond small agent groups.
4. MACP Architecture and Core Components
The MACP architecture employs a distributed coordination model
consisting of three primary components: Consensus Coordinators,
Participating Agents, and Decision Domains. This architecture is
designed to scale horizontally while maintaining fault tolerance
and ensuring efficient consensus across diverse agent populations.
The system operates on the principle of domain-partitioned
consensus, where agents are organized into logical groupings based
on their functional roles, trust relationships, or organizational
boundaries. Each Decision Domain maintains its own consensus state
and can interact with other domains through well-defined inter-
domain protocols.
Consensus Coordinators serve as the orchestration layer for MACP
operations within each Decision Domain. A Consensus Coordinator
MUST be capable of maintaining the current consensus state,
managing proposal queues, and coordinating message distribution
among Participating Agents. Coordinators are responsible for
implementing the selected consensus algorithm, enforcing quorum
requirements, and ensuring message ordering consistency. In
deployments requiring high availability, multiple Consensus
Coordinators MAY operate in a redundant configuration using leader
election mechanisms similar to those defined in Raft consensus
algorithms. Coordinators MUST implement Byzantine fault tolerance
measures when operating in environments where malicious behavior
is possible, maintaining consensus integrity even when up to one-
third of coordinators exhibit arbitrary failures.
Participating Agents represent the autonomous entities that
contribute to consensus decisions within the MACP framework. Each
Participating Agent MUST maintain a unique identity within its
Decision Domain and possess the capability to generate, evaluate,
and vote on consensus proposals. Agents are classified into one of
three participation modes: Active Participants that can both
propose and vote on decisions, Voting Participants that can vote
but not propose, and Observer Participants that receive consensus
results but do not participate in the decision process.
Participating Agents MUST implement proposal validation logic
appropriate to their domain context and SHOULD incorporate
reputation tracking mechanisms to assess the trustworthiness of
proposals from other agents.
Decision Domains establish the scope and context for consensus
operations, defining the set of agents authorized to participate
in specific types of decisions. A Decision Domain MUST specify its
consensus model (proof-of-authority, weighted voting, or
reputation-based), quorum requirements, and decision binding
policies. Domains operate independently but MAY establish inter-
domain communication channels for coordinating decisions that span
multiple domains. The domain configuration MUST include conflict
resolution parameters, timeout specifications, and rollback
procedures to handle consensus failures gracefully.
The interaction patterns between these components follow a
structured request-response model augmented with publish-subscribe
mechanisms for state synchronization. When a Participating Agent
initiates a consensus proposal, it MUST first submit the proposal
to its designated Consensus Coordinator, which validates the
proposal format and participant authorization. The Coordinator
then distributes the proposal to all eligible Participating Agents
within the Decision Domain, collecting votes according to the
configured consensus algorithm. Upon reaching quorum and achieving
consensus, the Coordinator publishes the binding decision to all
participants and updates the domain's consensus state. Failed
consensus attempts trigger the domain's configured rollback
procedures, allowing the system to maintain consistency despite
partial failures or network partitions.
5. Consensus Algorithms and Message Formats
MACP implements multiple consensus algorithms to accommodate
different operational requirements and network conditions. The
base specification MUST support the Practical Byzantine Fault
Tolerance (pBFT) algorithm adapted for multi-agent environments,
while implementations MAY support additional algorithms including
RAFT consensus for non-Byzantine scenarios and novel reputation-
weighted consensus for environments with established agent trust
relationships. The pBFT implementation assumes a maximum of f
Byzantine agents out of 3f+1 total participating agents, providing
safety and liveness guarantees under standard network assumptions.
Each consensus algorithm is identified by a unique Algorithm
Identifier (AID) registered with IANA as specified in Section 9.
The MACP consensus process follows a four-phase protocol:
Proposal, Pre-voting, Voting, and Commitment. During the Proposal
phase, any authorized agent MAY submit decision proposals to the
designated consensus coordinator for the relevant coordination
domain. The Pre-voting phase allows agents to signal their
preliminary position and identify potential conflicts or
dependencies with other pending proposals. The Voting phase
requires participating agents to submit cryptographically signed
votes within a specified timeout window, with vote validity
determined by the agent's authorization level and current
reputation score. The Commitment phase broadcasts the final
decision and requires acknowledgment from a quorum of agents
before considering the consensus binding.
MACP defines standardized message formats using JSON serialization
with mandatory digital signatures following RFC 7515 (JSON Web
Signature). All consensus messages MUST include a common header
containing the message type, consensus session identifier,
timestamp, originating agent identifier, and cryptographic
signature. Proposal messages additionally contain the proposed
decision payload, expected quorum size, voting timeout duration,
and conflict resolution parameters. Vote messages include the
proposal hash, agent's decision (ACCEPT, REJECT, ABSTAIN), voting
weight, and optional reasoning metadata. Commitment messages
broadcast the final consensus result, participating agent list,
vote tally, and binding duration for the agreed decision.
Message validation requires verification of agent authorization,
signature authenticity, and temporal constraints before
processing. Agents MUST reject messages with invalid signatures,
expired timestamps beyond the configured clock skew tolerance, or
originating from agents not authorized for the specific
coordination domain. Vote aggregation follows the specified
consensus algorithm with additional validation for vote weight
consistency and duplicate vote detection. The consensus
coordinator MUST broadcast commitment messages to all
participating agents and maintain an audit log of the complete
consensus session for accountability purposes as defined in
existing agent attestation frameworks.
Timeout handling and failure recovery mechanisms ensure liveness
properties under adverse network conditions. If insufficient votes
are received within the voting timeout window, the consensus
coordinator MUST initiate a new consensus round with an
exponentially increasing timeout duration, up to a maximum
threshold defined in the coordination domain configuration.
Network partition scenarios are addressed through coordinator
election protocols that prevent split-brain consensus decisions.
Failed consensus attempts trigger rollback procedures that notify
all participating agents of the unsuccessful coordination attempt
and release any provisionally allocated resources pending the
consensus outcome.
6. Conflict Resolution and Decision Binding
Conflict resolution in MACP occurs when multiple competing
proposals are submitted simultaneously or when agents disagree on
the validity or priority of proposed decisions. When conflicts are
detected during the proposal phase, participating agents MUST
invoke the conflict resolution mechanism before proceeding with
the voting phase. The protocol defines three primary conflict
types: proposal conflicts (multiple proposals for the same
decision domain), timing conflicts (simultaneous submissions
within the conflict detection window), and validity conflicts
(disagreement on proposal prerequisites or constraints). Agents
MUST maintain a conflict detection buffer with a configurable
timeout period (default 30 seconds) to identify competing
proposals before initiating consensus procedures.
The tie-breaking procedure activates when voting results in
equivalent support for multiple proposals or when no proposal
achieves the required quorum threshold. MACP employs a
hierarchical tie-breaking mechanism starting with proposal
priority levels, followed by submitter reputation scores, and
finally deterministic hash-based selection using the combined hash
of conflicting proposal identifiers. Participating agents MUST
apply tie-breaking rules in the specified order and MUST reach
agreement on tie-breaking criteria during the initial coordination
domain establishment. When tie-breaking fails to resolve
conflicts, the consensus coordinator MUST initiate a cooling-off
period of at least 60 seconds before allowing resubmission of
conflicting proposals.
Decision binding ensures that consensus outcomes are enforced
across all participating agents through cryptographic commitment
and distributed verification mechanisms. Once consensus is
achieved, all participating agents MUST generate binding
commitment messages containing the decision hash, their digital
signature, and a commitment timestamp. The binding phase requires
acknowledgment from at least the same quorum that approved the
original proposal within a configurable binding timeout (default
120 seconds). Agents MUST store binding commitments in their local
decision ledger and MUST reject future proposals that violate
committed decisions unless explicitly superseded through the
decision override mechanism.
Timeout handling addresses scenarios where consensus cannot be
achieved within specified time bounds or when participating agents
become unresponsive during critical phases. MACP defines distinct
timeout periods for each consensus phase: proposal timeout
(default 60 seconds), voting timeout (default 180 seconds), and
binding timeout (default 120 seconds). When timeouts occur, the
consensus coordinator MUST broadcast a timeout notification and
initiate graceful degradation procedures, which may include
reducing quorum requirements, extending timeout periods, or
aborting the consensus attempt. Agents that fail to respond within
timeout periods MUST be temporarily excluded from the current
consensus round but MAY rejoin subsequent rounds.
Rollback mechanisms provide recovery capabilities when consensus
failures occur after the voting phase or when binding commitments
cannot be properly established. Rollback procedures MUST be
initiated when binding acknowledgments fall below the required
threshold, when Byzantine fault detection identifies compromised
consensus results, or when critical participating agents report
implementation failures. The rollback process requires the
consensus coordinator to broadcast rollback notifications
containing the failed consensus identifier, rollback reason code,
and reversion instructions. All participating agents MUST
acknowledge rollback notifications, remove associated decision
commitments from their local ledgers, and reset their consensus
state to allow for subsequent retry attempts with modified
parameters or participant sets.
7. Integration with Existing Agent Protocols
MACP is designed to operate as an overlay protocol that integrates
seamlessly with existing agent-to-agent communication frameworks
and infrastructure. Implementations MUST support integration with
standard authentication protocols including OAuth 2.0 [RFC6749],
OpenID Connect, and X.509 certificate-based authentication systems
commonly deployed in enterprise environments. MACP consensus
messages SHOULD leverage existing secure transport mechanisms such
as TLS 1.3 [RFC8446] or DTLS for UDP-based communications,
ensuring that consensus operations benefit from established
security practices without requiring separate cryptographic
implementations.
Integration with agent accountability frameworks requires MACP
implementations to maintain comprehensive audit trails of
consensus participation and decision outcomes. Consensus
coordinators MUST log all proposal submissions, voting records,
and final decisions in formats compatible with existing audit and
compliance systems. When operating alongside agent attestation
protocols, MACP SHOULD verify agent identity and authorization
status before allowing participation in consensus processes,
utilizing existing identity providers and policy enforcement
points where available. The protocol defines standard interfaces
for querying agent reputation scores and authorization levels from
external accountability systems.
MACP consensus operations MUST be designed to coexist with
workflow management and orchestration platforms commonly used in
distributed AI deployments. Implementations SHOULD provide APIs
and event notifications that allow workflow systems to trigger
consensus processes when collective decisions are required, and to
receive binding consensus outcomes for subsequent workflow
execution. The protocol supports asynchronous integration patterns
where consensus results can be delivered to workflow systems
through message queues, webhooks, or polling interfaces, ensuring
compatibility with diverse orchestration architectures.
For environments utilizing existing agent-to-agent communication
protocols such as FIPA-ACL or custom REST-based agent APIs, MACP
provides adapter interfaces that translate consensus-specific
messages into native communication formats. Protocol
implementations MAY offer plugin architectures that allow custom
integration modules for proprietary agent communication systems,
while maintaining core consensus algorithm integrity. Standard
message mapping templates are provided for common integration
scenarios, reducing implementation complexity for organizations
with established agent communication infrastructure.
The protocol includes provisions for gradual deployment in mixed
environments where only a subset of agents support MACP consensus
mechanisms. Non-MACP agents MAY participate in consensus processes
through proxy agents that translate between native agent protocols
and MACP message formats, though such deployments SHOULD implement
additional verification mechanisms to ensure proxy agent fidelity.
Integration guidelines specify fallback procedures for scenarios
where consensus mechanisms are unavailable, allowing graceful
degradation to existing coordination approaches while maintaining
system stability.
8. Security Considerations
Security considerations for MACP deployment are paramount given
the distributed nature of multi-agent systems and the potential
for malicious actors to compromise consensus integrity. The
protocol MUST implement comprehensive threat mitigation strategies
to address attacks specific to distributed consensus mechanisms.
Primary security concerns include Sybil attacks where malicious
actors create multiple false agent identities to gain
disproportionate voting power, coordination attacks where
compromised agents collude to manipulate consensus outcomes, and
consensus manipulation through message tampering or replay
attacks. Additionally, MACP implementations MUST consider denial-
of-service attacks targeting consensus coordinators, eclipse
attacks isolating honest agents from the consensus network, and
long-range attacks where compromised agents attempt to rewrite
historical consensus decisions.
Cryptographic requirements for MACP implementations MUST include
strong identity verification mechanisms to prevent unauthorized
participation in consensus processes. Each participating agent
MUST possess a cryptographically verifiable identity backed by
public-key infrastructure or distributed identity systems such as
those defined in [RFC6960] and emerging decentralized identity
standards. Digital signatures MUST be used for all consensus
messages including proposals, votes, and commitments, with
signature schemes providing at least 128-bit security strength as
specified in [RFC3766]. Message integrity MUST be protected
through cryptographic hash functions resistant to collision
attacks, and implementations SHOULD employ hash-based message
authentication codes (HMAC) for additional verification. Time-
based replay attack prevention MUST be implemented through message
timestamps and nonce mechanisms, with strict validation of message
freshness windows.
Identity verification mechanisms MUST prevent Sybil attacks
through robust agent authentication and reputation tracking
systems. MACP implementations SHOULD integrate with existing
Public Key Infrastructure (PKI) systems or emerging decentralized
identity frameworks to establish verifiable agent identities.
Consensus coordinators MUST maintain authoritative lists of
eligible participating agents and regularly validate agent
credentials against trusted identity providers. Multi-factor
authentication SHOULD be employed for high-stakes consensus
decisions, potentially including hardware security module (HSM)
attestation or trusted execution environment verification. Agent
reputation systems MAY be implemented to track historical behavior
and adjust voting weights based on demonstrated trustworthiness,
though such systems MUST include mechanisms to prevent reputation
manipulation attacks.
Protection mechanisms for consensus integrity MUST address both
technical and game-theoretic attack vectors inherent in
distributed decision-making systems. Byzantine Fault Tolerant
consensus algorithms MUST be configured to handle the maximum
expected number of malicious agents according to theoretical
bounds, typically supporting up to f faulty agents in a network of
3f+1 total agents. Network-level protections SHOULD include
encrypted communication channels using protocols such as TLS 1.3
[RFC8446] and distributed denial-of-service (DDoS) mitigation
strategies to ensure consensus availability. Implementations MUST
implement consensus finality mechanisms that prevent retroactive
modification of agreed-upon decisions and provide cryptographic
proofs of consensus achievement. Regular security audits and
penetration testing SHOULD be conducted on MACP implementations,
with particular attention to consensus algorithm correctness and
cryptographic implementation vulnerabilities.
Economic and incentive-based security measures SHOULD be
considered to discourage malicious behavior and ensure honest
participation in consensus processes. Stake-based consensus
mechanisms MAY be implemented where agents must commit resources
or reputation to participate in decision-making, creating economic
disincentives for malicious behavior. Slashing mechanisms SHOULD
be employed to penalize agents that violate consensus rules or
demonstrate Byzantine behavior. However, such economic measures
MUST be carefully designed to prevent wealth concentration attacks
and ensure broad participation accessibility. Monitoring and
anomaly detection systems SHOULD continuously analyze consensus
patterns to identify potential coordinated attacks or unusual
voting behaviors that may indicate compromise. Emergency response
procedures MUST be established to handle detected security
incidents, including mechanisms for temporarily suspending
consensus participation of suspected malicious agents and
initiating incident response protocols.
9. IANA Considerations
This document requests IANA to create and maintain several new
registries to support the Multi-Agent Consensus Protocol (MACP)
and ensure protocol extensibility and interoperability. The
registries defined in this section will enable standardized
identification of protocol elements while allowing for future
enhancements and vendor-specific extensions without creating
conflicts or ambiguity in multi-agent consensus implementations.
IANA is requested to establish a "Multi-Agent Consensus Protocol
(MACP) Parameters" registry group containing three distinct
registries. The first registry, "MACP Message Types", SHALL
contain identifiers for all MACP message types including consensus
proposals, votes, commitments, and administrative messages.
Message type identifiers MUST be allocated as 16-bit unsigned
integers in the range 0x0000-0xFFFF, with values 0x0000-0x7FFF
reserved for IETF-defined message types and values 0x8000-0xFFFF
available for private use and experimental implementations.
Registration of new message types in the IETF range requires
Standards Action as defined in RFC 8126, and MUST include a
complete message format specification and security considerations.
The second registry, "MACP Consensus Algorithm Identifiers", SHALL
contain unique identifiers for consensus algorithms supported by
MACP implementations. Algorithm identifiers MUST be allocated as
UTF-8 strings following the pattern "algorithm-name.version" with
a maximum length of 64 characters. The registry MUST include
algorithm names, version numbers, reference specifications,
security properties, and applicable use case constraints for each
entry. Initial registry entries SHALL include "pbft.1.0" for
Practical Byzantine Fault Tolerance, "poa.1.0" for Proof of
Authority, and "weighted-vote.1.0" for weighted voting consensus.
New algorithm registrations require Expert Review with designated
experts having demonstrated expertise in distributed consensus
mechanisms and multi-agent systems.
The third registry, "MACP Conflict Resolution Methods", SHALL
contain identifiers for standardized conflict resolution
procedures used when multiple competing proposals achieve similar
consensus scores. Resolution method identifiers MUST follow the
same UTF-8 string format as consensus algorithms and include
detailed descriptions of resolution logic, fairness guarantees,
and termination conditions. Registration requires Expert Review
and MUST demonstrate deterministic behavior across all
participating agents. Initial entries SHALL include "timestamp-
priority.1.0", "hash-ordering.1.0", and "weighted-random.1.0" with
complete algorithmic specifications.
IANA is further requested to establish a "MACP Extension
Parameters" registry for protocol extension identifiers used in
MACP header fields and capability negotiation. Extension
identifiers MUST be allocated as reverse DNS notation strings to
prevent conflicts and enable vendor-specific extensions while
maintaining global uniqueness. The registry SHALL operate under
First Come First Served allocation policy as defined in RFC 8126,
requiring only basic documentation of the extension purpose and
format. All registry entries MUST include contact information for
the registering organization and SHOULD reference publicly
accessible specification documents for interoperability purposes.
Author's Address
Generated by IETF Draft Analyzer
2026-03-07
Reference in New Issue View Git Blame Copy Permalink