The Global Orientation Barrier in Step-Duplicating Recursors: Impossibility, Modular Escape, and a Certified Witness

Deze paper identificeert en formaliseert in Lean 4 een onmogelijkheidsbarrière voor directe compositiebewijzen bij stap-duplicerende recursoren, demonstreert hoe projectiemethoden deze barrière omzeilen, en levert een volledig geverifieerde certificeringsketen voor een specifiek voorbeeldsysteem dat door geautomatiseerde tools als TTT2 wordt bevestigd.

Moses Rahnama

Gepubliceerd 2026-03-06
📖 5 min leestijd🧠 Diepgaand

Each language version is independently generated for its own context, not a direct translation.

De Onzichtbare Muur in de Rekenmachine: Een Verhaal over KO7

Stel je voor dat je een enorme, complexe rekenmachine bouwt. Deze machine werkt met blokken die je kunt stapelen, samenvoegen en herschikken volgens een strikt setje regels. Je wilt weten: stopt deze machine ooit, of blijft hij voor eeuwig doorgaan met rekenen?

In de wereld van informatica noemen we dit "terminatie". Meestal is het makkelijk om te bewijzen dat een machine stopt: je telt gewoon de blokken. Als elke stap de stapel kleiner maakt, stopt het vanzelf.

Maar in dit paper (geschreven door Moses Rahnama) ontdekken de auteurs een geheime valkuil, een "onzichtbare muur" die voorkomt dat we dit op de gebruikelijke manier kunnen bewijzen. Ze noemen dit de "Global Orientation Barrier".

Hier is hoe het werkt, vertaald naar alledaagse taal:

1. De Magische Kloon (De "Step-Duplicating Recursor")

Stel je een regel voor in je rekenmachine die zegt: "Als je een stapel hebt, maak dan een kopie van die stapel en doe er nog een nieuwe stapel bij."

In de wiskunde heet dit een duplicerende recursor.

  • Links (De invoer): Je hebt één blok s.
  • Rechts (De uitvoer): Je hebt nu twee blokken s (één direct, één in een nieuwe stapel).

Het probleem? De machine is slim genoeg om te stoppen, maar de gewone meetlat die we gebruiken om te bewijzen dat hij stopt, faalt.

2. De "App-Lus" (De Valstrik)

De auteurs hebben een heel klein, simpel systeem bedacht genaamd KO7. Het is als een Lego-set met slechts 7 soorten blokken en 8 regels.
Er zit een speciaal blok in, laten we het app noemen. Dit blok is saai; het doet niets. Het is gewoon een doosje.

Wanneer de machine de "kloon-regel" gebruikt, gebeurt er iets vreemds:
De nieuwe kopie van het blok s wordt opgesloten in een doosje (app).

  • De realiteit: De machine stopt omdat de "tel-regel" (een ander blokje, delta) kleiner wordt.
  • De illusie: Voor de gewone meetlat ziet het eruit alsof de machine meer werk heeft gekregen, omdat er nu twee s-blokken zijn in plaats van één. De app-doosjes verbergen de kopieën zo goed dat de meetlat denkt: "Hé, er is meer massa! Dit gaat nooit stoppen!"

Dit noemen ze de "App Trap". De duplicatie is er echt, maar voor de meetlat is het een "dode massa" die niets doet.

3. De Twee Manieren om te Kijken

Het paper vergelijkt twee manieren om te proberen te bewijzen dat de machine stopt:

  • Manier A: De Global Aggregator (De "Totaal-teller")
    Deze methode telt alles bij elkaar op. Hoeveel blokken zijn er? Hoe groot is de stapel?

    • Het probleem: Omdat de machine twee kopieën maakt, ziet de teller de stapel groeien. De teller denkt: "Onmogelijk, dit wordt oneindig!"
    • Het resultaat: De auteurs bewijzen (met een computer die alles nagerekend heeft in Lean 4) dat deze manier nooit werkt voor dit type machine. Het is een wiskundige onmogelijkheid. Het is alsof je probeert een auto te stoppen door te tellen hoeveel brandstof erin zit, terwijl de auto juist brandstof verbruikt om te bewegen. De teller ziet alleen de toevoer, niet het verbruik.
  • Manier B: De Modular Breaker (De "Scheur-methode")
    Deze methode (genaamd Dependency Pairs) kijkt niet naar de hele stapel, maar splitst het probleem op.

    • Ze zeggen: "Laten we de 'dode massa' in de app-doosjes negeren. Kijk alleen naar de 'tel-regel' (delta)."
    • Als je alleen naar de tel-regel kijkt, zie je duidelijk dat die kleiner wordt. De machine stopt.
    • Het resultaat: Deze methode werkt perfect. Ze "ontsnappen" aan de muur door blind te zijn voor de kopieën die in de doosjes zitten.

4. De Gecertificeerde Bewijslast

De auteurs hebben dit niet zomaar gezegd. Ze hebben:

  1. Een computerbewijs (Lean 4): Ze hebben een programma geschreven dat wiskundig bewijst dat Manier A (de teller) altijd faalt voor dit systeem.
  2. Een externe check (TTT2): Ze hebben de machine voorgelegd aan een beroemde terminatie-tool (TTT2). Die tool kon Manier A niet vinden (het gaf "MAYBE" of faalde), maar Manier B (de scheur-methode) gaf direct "YES, het stopt!".
  3. Een veilige versie: Ze hebben een "veilige versie" van de machine gemaakt (SafeStep) waar ze kunnen bewijzen dat hij stopt, en zelfs een programma hebben geschreven dat elke berekening tot een eindresultaat brengt (een "normalizer").

5. Waarom is dit belangrijk?

Dit paper is een soort "grensverkenning". Het laat zien dat er een fundamentele muur bestaat tussen twee soorten wiskundige bewijzen:

  • Als je probeert alles in één grote som te tellen, mislukt het bij systemen die dingen kopiëren.
  • Als je slim bent en alleen kijkt naar de essentie (de tel-regel) en negeert de rommel (de kopieën in doosjes), dan lukt het wel.

De grote les:
Soms is het antwoord op een probleem niet om harder te tellen, maar om te erkennen dat sommige dingen die je ziet (de kopieën) eigenlijk niets betekenen voor het eindresultaat. De "muur" is niet in de machine zelf, maar in onze manier van kijken.

Samenvattend in één zin:
De auteurs hebben bewezen dat je een bepaalde soort rekenmachine niet kunt bewijzen dat hij stopt door gewoon te tellen (want hij maakt te veel kopieën), maar dat je het wel kunt doen door slim te negeren wat er in de "doosjes" zit. En ze hebben dit allemaal met een computer bewezen, zodat niemand het kan ontkennen.