Given the eUTXO model where can we store global state on-chain? Consider the Pausable ERC20 token wherein the token can be paused. How can we create equivalent behavior using Plutus? It appears that we cannot define a global flag called pause that can be tested before every transfer.
I can see how we can update the validators in the minting policy to perform a bunch of checks but am not able to see where we can set a flag that can be read in the validator.
I am most probably missing something. Would be great to get some help with this.
Think about the use case of what is really needed. Try to step away from hacks added to Ethereum to allow projects to prevent flooding and failures due to their network issues during various hard fork “down times”. What would a deterministic finite state machine do in this case?
Pass an off-chain determined input to deny execution?
Check a condition to determine a boolean value to deny execution on-chain?
Fail the execution with relevant validation error before submitting to blockchain?
Provide a processing queue off-chain to ensure the flags and checks are not needed?
Hybrid approach of the above?
If you answered #3 you are on the right track but any of these options “technically” work as do other worse hacks like baking the inability to handle scalability into your standards. ETH pausable is an example of “there is a huge bug we need a fast way to stop it” not a real solution.
Thanks @DinoDude for your response. The usecase is beyond just the “pausing” example I gave. I want to understand the ability to manage global state. Consider a different usecase of building an application that is a registry of different services. How can I list all services in one go? Short of iterating every transaction that added a service is there a way to enumerate all services directly in the smart contract? This is trivial on Ethereum as I can just query the smart contract.
Again this is an example to illustrate what we are trying to achieve. If there is no way to do this without having to iterate thru all the transaction objects then that is the answer - I just wanted a confirmation.
I think the above request of a pauseable token is possible (and it should since plutus is Turing complete). What one can do is create a bijective function that maps the key of a holder of you pauseable token to an utxo at a smart contract containing these tokens. In the contract this bijection is used to verify that only the token holden van spend the pauseable token at that script address. Here spending means changing the key value at the script address with the bijection.
In addition the script could check whether trades are even allowed by checking whether a certain nft is present (there are more ways to implemt this). Note that now the tokens are not in the wallet of a holder but at a script address, it is perhaps a good idea to mint fake tokens equivalent to send to the wallet of a holden that represent the tokens only his address can spend (and implent that these are burnt when a transaction is made with the real token to keep the values the same)
Are you referring to the “extended” parts of the eUTXO model then? In short, including datum in your smart contract or transaction allows you to include custom state.
Attaching meta data during the transaction that mints a token confers both state and the ability to have a holder or owner of it. If the token itself confers the state then the most recent transaction can update or more aptly re-issue new state using the same policy.
Tracking relevant transactions for your application has near limitless solutions. Simply querying the ledger via SQL with cardano-db-sync, REST web service API aggregate, etc allows verification of global state with or without tokens off-chain.
To control the use of a service you can require your application token as input and give it back as output to the wallet address providing the token via an intra-wallet transaction.
To my knowledge there is no way to prevent transfer of a native token between wallets but I am not sure if that’s what you meant. The application or smart contract could reject token inputs with “compromised identity” due to transfer history as part of their validator script but that would be ludicrously limiting to users as there are many legitimate reasons to use more than one wallet.
@fermat reply has much more detailed post about transfer control for identity and governance.
You can also checkout the Atala PRISM project underway for more insight.
Edit: I just realized you may have gotten caught up in how Ethereum smart contracts have state validation issues and can fail during execution. This is impossible in Cardano as all smart contracts and resulting transactions must be deterministic! Due to this it is actually possible to calculate transaction fee and validation both on-chain and off-chain to ensure there is no way any transaction can fail if executed with the correct I/O!