Simplicity

इसका core mathematically defined denotational और operational semantics वाले छोटे typed combinator set से बनता है। Rocq का formal model language, implementation और किसी खास program के properties के proofs को machine-check करने देता है। [1]

Language में unbounded loops या general recursion नहीं है, इसलिए execution से पहले computation, memory और data की upper bounds निकाली जा सकती हैं। Program को unknown gas cost पर रुकना या हमेशा चलते रहना नहीं चाहिए। [1]

Program एक merklized expression tree है और खर्च करते समय unused branches को उनके Merkle root से बदला जा सकता है। Validator पूरे program की commitment जाँचता है, लेकिन on-chain केवल जरूरी path और witness data खुलते हैं। [1]

Jet किसी खास Simplicity expression को पहचानकर optimized native function से चलाता है। Consensus safety के लिए jet result को expression की reference semantics से ठीक-ठीक मिलना चाहिए; jet कोई छिपा नया अर्थ नहीं जोड़ता। [1]

libSimplicity में C का minimal consensus-sensitive runtime, Haskell के reference और generator parts तथा Rocq का formal model है। ये layers एक-दूसरे को check करती हैं, पर repository साफ कहती है कि language और implementation अभी विकसित हो रहे हैं। [2]

SimplicityHL अधिक readable Rust-जैसी language है जो Simplicity bytecode में compile होती है। Project खुद इसे work in progress और production-ready नहीं बताता; contract audit में source, compiler, bytecode, witness और jets शामिल होने चाहिए। [3]

Simplicity को 2025 में Liquid mainnet पर deploy किया गया। Liquid कई assets और Confidential Transactions वाली federated sidechain है, इसलिए यह Bitcoin mainnet consensus में activation नहीं है; उसके लिए अलग proposal और soft fork चाहिए। [4]

Formal semantics सही economic intent, सुरक्षित keys या भरोसेमंद counterparty की guarantee नहीं देती। Verification में low-level program, SimplicityHL tools, खास jet set, Liquid version और hypothetical Bitcoin integration को अलग रखना चाहिए। [2]