Re-introduce Initial.compiledValidator
Likely got lost during rebase
Likely got lost during rebase
import Hydra.Contract.Commit (SerializedTxOut (..))
import qualified Hydra.Contract.Commit as Commit
import Hydra.Contract.Encoding (encodeTxOut)
import Ledger.Typed.Scripts (TypedValidator, ValidatorTypes (..))
import Ledger.Typed.Scripts (TypedValidator, ValidatorType, ValidatorTypes (..))
import qualified Ledger.Typed.Scripts as Scripts
import Plutus.Codec.CBOR.Encoding (encodingToBuiltinByteString)
import Plutus.V1.Ledger.Ada (fromValue, getLovelace)
import PlutusTx (CompiledCode)
import qualified PlutusTx
import PlutusTx.IsData.Class (ToData (..), fromBuiltinData)
compiledValidator
$$(PlutusTx.compile [||wrap||])
where
compiledValidator =
$$(PlutusTx.compile [||validator||])
`PlutusTx.applyCode` PlutusTx.liftCode Commit.validatorHash
wrap = Scripts.wrapValidator @(DatumType Initial) @(RedeemerType Initial)
compiledValidator :: CompiledCode (ValidatorType Initial)
compiledValidator =
$$(PlutusTx.compile [||validator||])
`PlutusTx.applyCode` PlutusTx.liftCode Commit.validatorHash
-- | Get the actual plutus script. Mainly used to serialize and use in
-- transactions.
validatorScript :: Script
* I removed an outdated comment * I renamed datum to datum_option (since it can be a hash or a datum)
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?
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'.