When trying to factor out the datum lookup, I realized that the commit validator datum might not be part of the commit transaction, i.e. it's optional as far as the ledger is concerned.
import Hydra.Contract.Commit (SerializedTxOut (..))
import qualified Hydra.Contract.Commit as Commit
import Hydra.Contract.Encoding (encodeTxOut)
import Hydra.Data.Party (Party)
import Ledger.Typed.Scripts (TypedValidator, ValidatorTypes (..))
import qualified Ledger.Typed.Scripts as Scripts
import Plutus.Codec.CBOR.Encoding (encodingToBuiltinByteString)
ScriptContext ->
Bool
checkCommit commitValidator committedRef [email protected]{scriptContextTxInfo = txInfo} =
checkCommittedValue && checkCommittedDatum
checkCommittedValue && checkSerializedTxOut
where
checkCommittedValue =
traceIfFalse "commitLockedValue does not match" $
traceIfFalse ("comittedValue: " `appendString` debugValue committedValue) $
commitLockedValue == initialValue + committedValue
checkCommittedDatum =
case scriptOutputsAt commitValidator txInfo of
[(dh, _)] ->
case getDatum <$> findDatum dh txInfo of
Nothing -> traceError "Invalid datum hash with no datum"
(Just da) ->
case fromBuiltinData @(Party, ValidatorHash, Maybe SerializedTxOut) da of
Just (_party, _headScriptHash, Nothing) ->
traceIfFalse "committed UTXO is not in output datum" $ isNothing committedRef
Just (_party, _headScriptHash, Just serialisedTxOut) ->
case txInInfoResolved <$> committedTxOut of
Nothing -> traceError "unexpected UTXO in output datum"
Just txOut ->
traceIfFalse "mismatch committed TxOut in datum" $
SerializedTxOut (encodingToBuiltinByteString (encodeTxOut txOut)) == serialisedTxOut
_ -> traceError "TODO"
_ -> traceError "expected single commit output"
checkSerializedTxOut =
case (committedTxOut, commitLockedSerializedTxOut) of
(Nothing, Nothing) ->
True
(Nothing, Just{}) ->
traceError "nothing committed, but TxOut in output datum"
(Just{}, Nothing) ->
traceError "committed TxOut, but nothing in output datum"
(Just txOut, Just serializedTxOut) ->
traceIfFalse "mismatch committed TxOut in datum" $
SerializedTxOut (encodingToBuiltinByteString (encodeTxOut txOut)) == serializedTxOut
initialValue =
maybe mempty (txOutValue . txInInfoResolved) $ findOwnInput context
committedValue =
maybe mempty (txOutValue . txInInfoResolved) committedTxOut
maybe mempty txOutValue committedTxOut
committedTxOut = do
ref <- committedRef
findTxInByTxOutRef ref txInfo
txInInfoResolved <$> findTxInByTxOutRef ref txInfo
commitLockedValue = valueLockedBy txInfo commitValidator
commitLockedSerializedTxOut =
case scriptOutputsAt commitValidator txInfo of
[(dh, _)] ->
case getDatum <$> findDatum dh txInfo of
Nothing -> traceError "expected optional commit datum"
(Just da) ->
case fromBuiltinData @(DatumType Commit.Commit) da of
Nothing -> traceError "expected commit datum type, got something else"
Just (_party, _headScriptHash, mSerializedTxOut) ->
mSerializedTxOut
_ -> traceError "expected single commit output"
debugValue = debugInteger . getLovelace . fromValue
-- | Show an 'Integer' as decimal number. This is very inefficient and only
Other small changes include: * Added a trace event `TDBInitialisingFromLMDBDone`. * Initialisation from an existing LMDB database does not rely on the default `LMDBLimits` anymore, and is passed a limits argument instead. TODO: We should decide whether we want to hardcode these limits to a a substantially large one, or possibly we could link these limits to a versioning number?
add cwbtc
attempt implementation
Other small changes include: * Added a trace event `TDBInitialisingFromLMDBDone`. * Initialisation from an existing LMDB database does not rely on the default `LMDBLimits` anymore, and is passed a limits argument instead. TODO: We should decide whether we want to hardcode these limits to a a substantially large one, or possibly we could link these limits to a versioning number?
![iohk-bors[bot]](https://avatars.githubusercontent.com/in/17473?v=4&s=80)
Updated crypto exchange rates chapter. I tried my best to address @rdlrt concerns. I would like to add that English is just my 3rd language, so I hope it is not too bad.
Previously, the sequence number of the database is written to disk as part of the on-disk database settings on every flush/write. Conceptually however, the settings of a database should not change on every flush or write. Instead, we make a dinstinction between on-disk database "settings" and "state", where the state can be updated in every write/flush, but the settings should generally be left untouched after database initialisation or node start-up.
Fixes #217.
This works because (a) JavaScript is ultimately single-threaded, (b) there's no execution preemption happening between a 'send' and a 'wait'.
This was using the raw Show instance of queries, which looks real bad for constructors with arity > 1 like HasTx.