• Top
    • Documentation
    • Books
    • Boolean-reasoning
    • Projects
      • Apt
      • Zfc
      • Acre
      • Milawa
      • Smtlink
      • Abnf
      • Vwsim
      • Isar
      • Wp-gen
      • Dimacs-reader
      • Pfcs
      • Legacy-defrstobj
      • C
      • Proof-checker-array
      • Soft
      • Farray
      • Rp-rewriter
      • Instant-runoff-voting
      • Imp-language
      • Sidekick
      • Ethereum
      • Leftist-trees
      • Java
      • Riscv
      • Taspi
      • Bitcoin
      • Zcash
      • Des
      • X86isa
      • Sha-2
      • Yul
      • Proof-checker-itp13
      • Regex
      • ACL2-programming-language
      • Json
      • Jfkr
      • Equational
      • Cryptography
      • Axe
      • Poseidon
      • Where-do-i-place-my-book
      • Aleo
        • Aleobft
          • Correctness
            • Unequivocal-dags-def-and-init
            • Same-committees-def-and-implied
            • Dag-omni-paths
            • Signer-records
            • Unequivocal-dags-next
            • Quorum-intersection
            • Dag-previous-quorum-def-and-init-and-next
            • Unequivocal-signed-certificates
            • Signed-previous-quorum
            • Nonforking-anchors-def-and-init-and-next
              • Nonforking-anchors-p-of-next
              • Nonforking-anchors-p
              • Nonforking-anchors-p-when-init
            • 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
    • Community
    • Std
    • Proof-automation
    • Macro-libraries
    • ACL2
    • Interfacing-tools
    • Hardware-verification
    • Software-verification
    • Math
    • Testing-utilities
  • Correctness

Nonforking-anchors-def-and-init-and-next

Invariant that committed anchors do not fork: definition, establishment, and preservation.

This is most of what is needed to show the non-forking of blockchains, given that, as proved elsewhere, the blockchain in each validator is determined by the anchors committed so far.

The non-forking of anchors could be proved from existing invariants, but if we did that, the final proof by induction would not work. Recall that we need to prove non-equivocation and blockchain non-forking simultaneously by induction, as discussed in unequivocal-dags-def-and-init and nonforking-blockchains-def-and-init. If we just proved the non-forking of anchors from existing invariants, which include non-equivocation, which depends on blockchain non-forking, and then proved non-forking of blockchains from non-forking of anchors, things would be circular, and not in the way that works with induction. Thus, here we prove the non-forking of anchors by showing that it is established in the initial states and it is preserved by all transitions.

Initially no anchors are committed, so clearly there is no forking. The only kind of events that changes the committed anchors is commit, which extends them. There are a few cases to consider, but in all cases the extension cannot cause forking; this is explained in detail below, in the proofs of preservation.

Here we define the invariant, we prove that it holds in all initial states, and we prove that it is preserved by all transitions. Elsewhere we prove that the invariant holds in every reachable state.

Subtopics

Nonforking-anchors-p-of-next
Preservation of the invariant: if the invariant holds in a system state, it also holds in the next system state.
Nonforking-anchors-p
Definition of the invariant: given two correct validators in the system, their sequences of committed anchor do not fork.
Nonforking-anchors-p-when-init
Establishment of the invariant: the invariant holds in any initial state.