While contract developers are using higher-level languages, such as ErgoScript (see its whitepaper: https://ergoplatform.org/docs/ErgoScript.pdf ), they are to be compiled into ErgoTree representation, which is stored on the blockchain. ErgoTree is not an assembly imperative language (like stack-based EVM assembly language), but a typed abstract syntax tree.
Roughly, a tree combines predicates of two kinds. Some predicates are about secret data, the simplest example is “ProveDlog(pk)” which means “check proof of knowledge of a secret corresponding to public key pk” (against a signature provided in a spending input.
Other predicates are about blockchain context and also the spending transaction, e.g. “HEIGHT > 100”.
During transaction processing, the tree is being first reduced to a tree which contains only crypto-predicates (by evaluating context-predicated with context at the moment of spending), then crypto-tree being is checked against a signature stored in the spending input. If everything is fine, then the box (the UTXO) can be spent. The crypto-tree combines different predicates using AND / OR / k-out-of-n conjectures.
This approach can be reused for other context representations, in other cryptocurrencies, CBDCs (Central Bank Digital Currencies), or even non-monetary digital objects where smart access could be needed.
In this regards ErgoTree is a kind of authentication language aka “smart signature”, see this presentation by Christopher Allen (covering ErgoTree under earlier name, Sigma-State):
In regards with implementation, early sigma-interpreter tried to distinguish context and crypto predicates and make the former ones replaceable. Then this approach was lost, and the current code is monolithic about that. Let’s see how sigma-rust will be done.