-
Notifications
You must be signed in to change notification settings - Fork 4
Programmable Pools
The Mintlayer blockchain is based on UTXO system to stay compatible with Bitcoin and Lightning Network. Programmable Pools are peripheral modules to add smart contract support on top of the Mintlayer UTXO system. While Tokens, NFTs and Oracles are first class (native) entities in Mintlayer, the purpose of Programmable Pools is to reduce the pollution of the network using the benefits of the Account system as well as automation produced by smart contracts. Therefore Programmable Pools, PPs hereafter, respect the state of the UTXO system on the mainchain and will not consume network resources. PPs can be used to execute general purpose programs, it is however, preferable to use the PP system only where a real-world benefit exists over the native UTXO system and the chainscript dialect of Bitcoin Script. Examples of these use-cases are pay out Dividends and collecting Tax, where there are a lot of transactions containing small amount of money. PPs operate using an account based system rather than the standard UTXO system. A PP will translate UTXO transactions in to a single state for it's usage. Calls to contracts can alter the storage of the contract, call other contracts or spend back the storage of the contract to UTXO system.
PPs are an interface between UTXO system and Pallet Contract which executes WebAssembly (Wasm) smart contracts. These can potentially be written in any Turing-Complete programming language that compiles to Wasm. However, using a language that specifically targets this module will make things a lot easier. One such language is ink! which is an eDSL that enables writing Wasm smart contracts in the Rust programming language.
PPs are not a new blockchain layer, they are a module within which users ask validators to processes their UTXO transactions differently. While the users can always make normal UTXO transactions with inputs and outputs, someone may decide to send her owned UTXO to a specific contract, instead of a usual public key address. They mention the contract address and some parameters for running that contract correctly, including gas fee. The remaining process will be transparent from the UTXO system until the contract creates an output for spending a value to a UTXO public key address, where a transaction appears on the UTXO system. User will be notified about contract-specific events.
PPs are an optional, temporary, local extension to pure UTXO validation process, where whole state transitions in accounts, and consensus on result of contracts execution will remain in the memory of the validators without any trace on the blockchain. PPs keep the track of contract to contract calls and manage the outputs of contracts. Using this mechanism, validation of special transactions is reduced to just a simple query. The validators will be incentivized with gas fee for executing the smart contract that is similar to Substrate weight system.
Contract calls are charged a gas fee to limit the amount of computational resources a transaction can use. When forming a contract transaction, a gas limit is specified. As the contract executes, gas is incrementally used up depending on the complexity of the computation. If the gas limit is reached before the contract execution completes, the transaction fails, contract storage is reverted, but the gas fee is not returned to the user. If the contract execution completes with remaining gas, it is to the user at the end of the transaction.
The module determines the gas price, which is a conversion between the Substrate weight system and a single unit of gas. Thus, to execute a transaction, a user must have a free balance of at least gas price * gas limit which can be spent.
The most fundamental aspect of PPs is safe interaction with the UTXO system. Since PPs are not allowed to create or burn tokens, the UTXO system provides a PP with funds and gas and then expects receiving transactions in UTXO format equal to the original funds eventually. So as to achieve the token conservation criteria, there are three additional output destination types in UTXO transaction: Create PP, Fund PP and Call PP. When a validator detects one of these three requests in the output of a UTXO transaction, it starts processing it immediately. All of them are spendable transactions to prevent UTXO set becoming too large. Deploying a contract in a PP takes two steps: First store the WebAssemby contract on the blockchain, second instantiate a new account, with new storage, associated with that contract. The PP converts the contract output to UTXO transaction by adding a reference of contract output to the list of UTXO transaction inputs. This is a replacement of unlocking signatures for contract outputs.
Programmble Pools are under active research and development. Current design is still polluting the network, it may be replaced by a totally new concept.
- Support for various programming languages
- Separate blockchain layer and consensus mechanism
- Support for formal validation or non-Turing-Complete contracts