Sequentia docs
Search
K

3.1. Orange pilled

Sequentia is a UTXO chain using Bitcoin Script, with a standard (non-turing) 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. 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. Instead, 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. 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 Bitcoin interoperability.
  3. 3.
    Sequentia can inherit practices developed explicitly for on-chain Bitcoin operations to improve privacy and scalability, 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. The aggregation can be made by a single service/exchange transferring multiple transactions in a limited timeframe (i.e., the withdrawal requests of exchange/services users), as well as through a peer-to-peer network among independent users (3) (§4.4).
Script-based smart contracts are chosen over Turing-complete environments (e.g., EVM, WASM), which means that the system cannot 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 the 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. 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 possibilities provided by a script-based system are sufficient and proportionate to Sequentia’s basic DeFi and DEX functionalities without incurring the risks of 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 very primitive script-based smart contracts are the multi-signature account and the time lock 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).