• Top
    • Documentation
    • Books
    • Boolean-reasoning
    • Projects
      • Apt
      • Zfc
      • Acre
      • Milawa
      • Smtlink
      • Abnf
      • Vwsim
      • Isar
      • Wp-gen
      • Dimacs-reader
      • Pfcs
      • Legacy-defrstobj
      • Proof-checker-array
      • Soft
      • C
      • Farray
      • Rp-rewriter
      • Riscv
      • Instant-runoff-voting
      • Imp-language
      • Sidekick
      • Leftist-trees
      • Java
      • Taspi
      • Bitcoin
      • Des
      • Ethereum
      • X86isa
      • Sha-2
      • Yul
      • Zcash
      • Proof-checker-itp13
      • Regex
      • ACL2-programming-language
      • Json
      • Jfkr
      • Equational
      • Cryptography
      • Poseidon
      • Where-do-i-place-my-book
      • Axe
      • Aleo
        • Aleobft
          • Correctness
            • Unequivocal-dags-def-and-init
            • Same-committees-def-and-implied
            • Dag-omni-paths
            • Signer-records
            • Unequivocal-dags-next
              • Unequivocal-dags-p-of-next
            • Quorum-intersection
            • Dag-previous-quorum-def-and-init-and-next
            • Unequivocal-signed-certificates
            • Signed-previous-quorum
            • Nonforking-anchors-def-and-init-and-next
            • Successor-predecessor-intersection
            • Fault-tolerance
            • Last-anchor-voters-def-and-init-and-next
            • Signer-quorum
            • Committed-redundant-def-and-init-and-next
            • Nonforking-blockchains-def-and-init
            • Blockchain-redundant-def-and-init-and-next
            • No-self-endorsed
            • Last-anchor-present
            • Anchors-extension
            • Nonforking-blockchains-next
            • Backward-closure
            • Last-blockchain-round
            • Dag-certificate-next
            • Omni-paths-def-and-implied
            • Ordered-blockchain
            • Simultaneous-induction
            • System-certificates
            • Last-anchor-def-and-init
            • Last-anchor-next
            • Dag-previous-quorum
            • Signed-certificates
            • Committed-anchor-sequences
            • Omni-paths
            • Last-anchor-voters
            • Unequivocal-dags
            • Nonforking-blockchains
            • Nonforking-anchors
            • Committed-redundant
            • Same-committees
            • Blockchain-redundant
          • Definition
          • Library-extensions
        • Aleovm
        • Leo
      • Bigmems
      • Builtins
      • Execloader
      • Solidity
      • Paco
      • Concurrent-programs
      • Bls12-377-curves
    • Debugging
    • Std
    • Community
    • Proof-automation
    • Macro-libraries
    • ACL2
    • Interfacing-tools
    • Hardware-verification
    • Software-verification
    • Math
    • Testing-utilities
  • Correctness

Unequivocal-dags-next

Invariant that DAGs are unequivocal: preservation.

As explained in unequivocal-dags-def-and-init, in order to prove that the non-equivocation of DAG is preserved by state transitions, we need to assume that the old state satisfies not only the non-equivocation of DAGs, but also the non-forking of blockchains. From that, here we prove that the new state satisfies the non-equivocation of DAGs.

At a high level, the reason why DAGs are unequivocal is the following. By contradiction, suppose that two validators (which may be the same) have two equivocal certificates in DAGs, one for each validator, i.e. the two certificates have the same author and round, but they are different certificates. Each certificate would be signed by a quorum of validators, in the active committee for the round of both certificates. Each validator calculates its own active committee for that round, but because of the assumed non-forking of blockchains, those two calculated active committees are the same (see same-committees-def-and-implied). Thus, by quorum intersection, and assuming that the committee is fault-tolerant, we must have at least one correct validator in both signer sets. But a correct validator would not have signed two different certificates with the same author and round, so the initial premise must not hold, i.e. there cannot exist equivocal certificates. The just mentioned fact that a correct validator does not sign two equivocal certificates amounts to the already proved invariant that the set of the certificates signed by a correct validator is unequivocal (see unequivocal-signed-certificates), which we use to prove this new invariant.

The above argument has to be spelled out more precisely for ACL2. The only two kinds of events that may extend DAGs (and could therefore potentially break non-equivocation) are create and accept.

A create event concerns the (correct) author of the certificate, which checks that the signers, including itself, of the new certificate are in the active committee and form a quorum. If a validator (the author or other) had already, in its DAG, a different certificate with the same author and round, the two certificates must have at least one common correct signer, whose signed certificates would thus be equivocal, but we know they are not, as already proved in unequivocal-signed-certificates.

An accept event concerns the (correct) validator who moves the certificate from the network to the DAG; the validator checks that the signers are in the active committee. If a validator (the one accepting the certificate, or another one) had already, in its DAG, a different certificate with the same author and round, the two certificates must have at least one common correct signer, whose signed certificates would thus be equivocal, but we know they are not, as already proved in unequivocal-signed-certificates.

Elsewhere we prove that the invariant holds in every reachable state.

Subtopics

Unequivocal-dags-p-of-next
Preservation of the invariant: if the invariant holds in a system state, it also holds in the next system state.