3.1. Orange pilled

Sequentia is a UTXO chain using Bitcoin Script, with a standard (non-turing complete) tokenization system.

Sequentia uses Bitcoin’s UTXO structure instead of an account-based model. From a certain point of view, the UTXO model is less efficient than the account-based model: since each transaction’s output is stored separately (even when sent to a single address), it is only possible to spend the entire transaction output. Therefore, most transactions must include change, creating what is commonly referred to as “dust” - smaller outputs that are costly to be transferred, given the fee’s weight relative to transaction volume. Despite this, the UTXO model has been chosen because of three essential features:

1. It is more privacy-oriented than other models because a single wallet usually utilizes multiple addresses, making it difficult and sometimes impossible to distinguish which ones belong to the same user. In contrast, account-based blockchains do not facilitate users’ privacy retention; for example, showing an address from a wallet may expose the users’ balance and the entire history of transactions not only in one token but in all tokens held by that wallet. With UTXO and Hierarchical Deterministic wallets (the most common Bitcoin wallets), it is instead possible to manage multiple addresses from the same wallet seed.

2. It is compatible with technologies already implemented in Bitcoin, such as HTLC-based smart contracts, including atomic swaps and the Lightning Network, that can be extended to allow swaps and DEXs. The combination of a UTXO system and Bitcoin script allows cross-chain interoperability with Bitcoin, while the addition of Anchoring (§3.4) makes this interoperability frictionless.)

3. Sequentia can inherit practices that were originally developed to improve privacy and scalability on Bitcoin, such as coinjoin and transaction batching with signature aggregation. Payments can be batched together (aggregated) in a single transaction, saving considerable space otherwise required for making a single transaction per payment. The practice of transaction batching is a particular focus in Sequentia’s value proposition. Aggregation can be made by a single service provider who transfers multiple transactions within a limited timeframe (e.g., the withdrawal requests of centralized exchange users), as well as through a peer-to-peer network among several independent users (3) (§4.4).

Script-based smart contracts are chosen over Turing-complete environments (e.g., EVM, WASM) which can process just about any rule set of data manipulation, resulting in infinite possibilities for developers to create smart contracts. Instead, Sequentia primarily relies on the Bitcoin-like script-based approach limited by a determined set of rules that must be followed. This approach sacrifices some versatility for higher safety, sustainability, and validation speed.

Generally, script-based smart contracts tend to produce less network pollution and execute faster than Turing-complete contracts, thus ensuring a more manageable environment for developers. As demonstrated by protocols that have taken the opposite approach, complicated architectures on blockchains may cause issues: having endless possibilities might end up clogging servers, while at its core, a Turing-complete system is not even required by most blockchain use cases since the majority of contracts do not even require a loop, and only a tiny percentage of smart contracts built on EVM truly require Turing-complete language functions (4). In order to prevent potentially infinite loops that require excessive resources, contract execution is generally limited by “gas” on EVM-based systems. However, transactions are nullified when a smart contract runs out of gas (the fee in gas is paid to the miner regardless). Therefore, it is necessary to provide enough gas in anticipation to cover the worst-case scenario, which is very difficult to foresee. It is one of the reasons why Turing complete smart contracts have shown a higher probability of breaking over time (5).

On the other hand, the flexibility provided by a script-based system is sufficient and proportionate to Sequentia’s basic DeFi and DEX functionalities without incurring the risks associated with Turing-completeness. Combining several simple scripts makes it possible to produce highly advanced contracts such as hashed timelock contracts (HTLC), whose potential and versatility are best exemplified by the Lightning Network. Two examples of very primitive script-based smart contracts are the multi-signature account and the timelock contract (6). Combining simple scripts like these makes it possible to create sophisticated contracts while keeping their basic components’ high reliability, efficiency, and predictability.

Footnotes/p3

3. This method is currently implemented with coinjoin in bitcoin wallets like Wasabi.

4. The following research says that only 6,9% of smart contracts built on the Ethereum Virtual Machine truly require Turing-complete language functions. It also notes that the vast majority of Ethereum’s smart contracts can be coded to function the same way on a Turing-incomplete machine. https://www.researchgate.net/publication/332072371_Do_Smart_Contract_Languages_Need_to_be_Turing_Complete

The Ethereum whitepaper (https://ethereum.org/en/whitepaper) reports that “Turing-incompleteness is not even that big of a limitation”. Out of all the contract examples that the Ethereum team had conceived when writing a whitepaper, only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code.

5. among historical failures, some of the more notable ones are the DAO hack and Parity’s multiple signature validation program.

6. Multi-signature requires a number n of signatures over m to unlock a specific unspent output, whereas time lock requires that the output is spent only after block x, or only n blocks after the event x occurred (event x might also be a particular transaction or block).