Skip to content

DAL Documentation Unclear About tz1 Key Behavior with attestation_with_dal #671

@michaelkernaghan

Description

@michaelkernaghan

The current DAL documentation at https://signatory.io/docs/bakers#baking-with-dal-data-availability-layer can be misinterpreted regarding which key types require the attestation_with_dal policy and when companion keys are needed.

Current Documentation Issues

1. Ambiguous Companion Key Requirement

The documentation states:

"BLS Consensus Keys (tz4): A companion key is mandatory for DAL attestations."

This can be misinterpreted to mean that:

  • Only tz4 keys participate in DAL attestations
  • The attestation_with_dal policy only applies to tz4 keys
  • tz1 keys don't need attestation_with_dal in signatory policy

2. Missing Clarification About tz1 Behavior

The documentation doesn't clearly explain that:

  • tz1 keys DO sign attestation_with_dal operations when DAL node is connected
  • The attestation_with_dal policy is required for ALL key types, not just tz4
  • The encoding is triggered by DAL node connectivity, not key type

Real-World Impact

Operators running tz1-only setups with DAL nodes may:

  1. Omit attestation_with_dal from their signatory policy (thinking it's only for tz4)
  2. Experience rejected attestation requests
  3. Miss attestation opportunities and rewards
  4. Spend time troubleshooting configuration issues

Expected Behavior (Verified Through Testing)

tz1 Keys with DAL Node Connected:

  • ✅ Baker sends attestation_with_dal requests to signatory
  • ✅ Signatory logs show "request=attestation_with_dal"
  • ✅ Signatory logs show "Signed attestation_with_dal successfully"
  • ✅ Attestations have bitset 0 (no shard attestation capability)
  • ✅ DAL rewards can still be earned
  • Without attestation_with_dal policy: Requests rejected

tz4 Keys with DAL Node Connected:

  • ✅ Baker sends attestation_with_dal requests for both consensus and companion keys
  • ✅ Attestations can have bitset > 0 (actual shard attestation)
  • ✅ Full DAL participation with shard attestation capability
  • Without attestation_with_dal policy: Requests rejected

Testing Environment

  • Network: Seoulnet
  • Protocol: PtSeouLo (023)
  • Signatory: v1.3.0 (ECAD Labs build)
  • Octez Baker: 23.2 (13afca5d)
  • Testing Period: October 6-7, 2025
  • Configurations Tested:
    • tz1-only (no secondary keys)
    • tz1 manager + tz4 consensus + tz4 companion

Evidence

Signatory Logs (tz1-only setup):

time="2025-10-07T04:35:21-07:00" level=info msg="Requesting signing operation" chain_id=NetXd56aBs1aeW3 lvl=1898666 pkh=tz1Y9fvKx9qx1T786QHAwu4iuPA3UUZCtDWE request=attestation_with_dal vault=File
time="2025-10-07T04:35:21-07:00" level=info msg="Signed attestation_with_dal successfully" chain_id=NetXd56aBs1aeW3 lvl=1898666 pkh=tz1Y9fvKx9qx1T786QHAwu4iuPA3UUZCtDWE request=attestation_with_dal vault=File

Baker Logs (tz1-only setup):

Oct 07 04:35:21 octez-baker-PtSeouLo: tz1Y9fvKx9qx1T786QHAwu4iuPA3UUZCtDWE has no assigned DAL shards at level 1898666
Oct 07 04:35:21 octez-baker-PtSeouLo: injected attestation (without DAL) for level 1898666

TzKT Evidence:

Proposed Solution

Update the documentation to:

  1. Clarify that attestation_with_dal policy is required for ALL key types when DAL node is connected
  2. Explain the difference between attestation encoding and shard attestation capability
  3. Specify that companion keys are only required for tz4 keys, not tz1
  4. Add examples showing tz1 behavior with DAL node connected

Suggested Documentation Updates

Update "Key Requirements" Section

Add clarification:

BLS Consensus Keys (tz4): A companion key is mandatory for DAL attestations with tz4 keys. Without it, tz4 bakers cannot produce DAL attestations with shard attestation capability.

Standard Keys (tz1/tz2/tz3): Can participate in DAL attestations without companion keys. The baker will sign attestation_with_dal operations with the consensus key (or manager key if no separate consensus key is configured). However, these attestations will have bitset 0 (no shard attestation capability) since DAL shard attestation requires BLS signature aggregation.

Add to "Critical Signatory Configuration" Section

Add important clarification:

Important: The attestation_with_dal policy applies to all key types (tz1, tz2, tz3, tz4) when a DAL node is connected to the baker. This is an encoding/policy distinction triggered by DAL node connectivity, not a key type requirement.

  • tz1/tz2/tz3 keys: Sign attestation_with_dal operations with empty DAL content (bitset 0)
  • tz4 keys: Can attest actual DAL shards (bitset > 0) when consensus + companion keys are properly configured
  • Both trigger the same signatory policy check for attestation_with_dal

Even if your baker uses only tz1 keys, you must include attestation_with_dal in your signatory policy when running with a DAL node, otherwise attestation requests will be rejected.

Update Configuration Example Comment

Change:

attestation_with_dal: # Required for DAL attestations

To:

attestation_with_dal: # Required for ALL key types when DAL node is connected

Benefits

These clarifications will:

  1. ✅ Help operators understand that attestation_with_dal policy is needed for all key types
  2. ✅ Prevent configuration errors where operators omit attestation_with_dal for tz1 setups
  3. ✅ Clarify the distinction between attestation encoding vs shard attestation capability
  4. ✅ Reduce troubleshooting time for operators setting up DAL with tz1 keys
  5. ✅ Align documentation with actual protocol behavior

Additional Context

This discovery was made during comprehensive testing of all key configuration scenarios for DAL attestations. The behavior is consistent with the Tezos protocol design where:

  • The DAL attestation encoding (attestation_with_dal) is a signing/policy layer distinction
  • The DAL shard attestation capability (bitset > 0) requires BLS keys for signature aggregation
  • Both are separate concerns that should be clearly distinguished in documentation

References


Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions