HAL vs Graph poate fi privit mai general astfel: Când modelăm "calculul", folosim - Încorporare superficială (scrie-o direct în limba gazdă), sau - Deep Embedding (codificarea ca structură de date)? 🧵

De la adâncime → adâncime, există mai multe puncte de proiectare: 1. Implementare directă în Rust / C++ 2. DSL integrat în limba gazdă 3. Un limbaj specializat complet nou Fiecare pas schimbă comoditatea pentru structură și analizabilitate.

În ZK, nu este suficient să rulezi un calcul — trebuie să o traducem și în constrângeri. Așadar, majoritatea sistemelor de demonstrație tind deja spre (2) sau (3): - Circom, PIL/PIL2 → limbaje de constrângeri personalizate + compilatoare - Plonky2 → fiecare poartă definește mai multe funcții semantice

Plonky3 merge mai departe cu trăsătura AirBuilder: același cod poate evalua martori, poate calcula reziduurile verificatorilor și poate elimina polinoamele de constrângeri. Multe zkVM-uri (SP1, Hypercube, OpenVM) adoptă Plonky3; Zisk este bazat pe PIL2. Acest lucru arată o tendință clară către reprezentări profunde, asemănătoare unor grafuri, ale calculului.