1. existing bitcoin script allows devs to do limited conditional lock/unlock of bitcoins. with OP_CAT (and potentially more op-codes) restored on mainnet later, we are enabled to achieve more operations. one example, with all op-codes re-enabled we implemented an UTXO-based swap in 2021 which utilizes OP_PUSH_TX and Sensible Contract to maintain the state of the given trading pair in a single inherited utxo. It allows thousands of swap trading pairs existing separately without interfering each other (parallelism-friendly).
2. for inscription based contract, you just write a standalone contract script and inscribe it (or its bytecode) into a typical inscription and have it executed. It behaves exactly the same like being executed on EVM, the difference is it's protected by Ordinals indexers not nodes (strong consensus). You can use recursive inscriptions to have the call/reference dependency graph to have contract invoking hierarchy. the next update of brc-20 after the brc20-swap update will be the programmable module (happening in Q3), which is a formulated implementation of this method. the programmable module allows people to write EVM-style contract and compile into the bytecode to be inscribed and executed by the indexers working collectively.

(these are written quickly in 10min, many aspects are not well elaborated, would be expanded into an article later, Lorenzo on 2024-05-28)

I had an interview explaining details of the first rabbit hole:

• https://coingeek.com/token-protocols-on-bsv-sensible-contract/

For the second, please refer to the open source implementation of brc20-swap the contract: https://github.com/brc20-devs/brc20-swap-contract the indexer: https://github.com/brc20-devs/brc20-swap-indexer the sequencer: https://github.com/brc20-devs/brc20-swap-sequencer-api

"the difference is it's protected by Ordinals indexers not nodes (strong consensus)"

could you explain this further please?

contracts on EVM are validated and executed by Ethereum nodes (the first-class consensus of a given blockchain). invalid contract is rejected and doesn't get the chance to the blocks.

contracts in inscriptions are validated and executed by Ordinals/brc-20 indexers (BestInSlots/OPI, UniSat, OKX, Nubit, etc..), not bitcoin nodes (1st-class consensus on bitcoin). Invalid contracts still get their ways into blocks as valid bitcoin transactions, but they will be invalidated by indexers like mis-typed brc-20 mintings as bad mintings.

The second-class consensus is weaker than the first one as it cannot prevent the ill inscriptions from getting into blocks. But it still works reliably for protocols like brc-20 and runes, by maintaining a shared consensus/ruleset between hundreds of indexing instances. It also provides additional level of flexibility that allows us to program in different languages (for example we use TypeScript in brc20-swap contracts, source code shared above) with a versatile execution environment.