chore: update README

Author: euonymos

README.md

@@ -1,59 +1,32 @@
-# CEM SDK
+# CEM Script
 
 ## Project pitch
 
-Define and reuse Cardano DApp logic via annotated CEM-machines, resulting in free implementations for:
+CEM Script is a framework to define Cardano DApp logic via annotated CEM-machines,
+resulting in free implementations for:
 
 * On-chain scripts
-* Tx building/submission/resubmission on L1/emulated testnet
-* Tx parsing/indexing
+* Transaction building/submission (off-chain)
+* Transaction parsing/indexing
 * Automatically testing invariants
 * Human-readable specs
 
-## Building
+## Documentation
+
+* [Getting Started Guide](https://github.com/mlabs-haskell/cem-script/blob/master/docs/getting_started.md)
+* [Goals and Design](https://github.com/mlabs-haskell/cem-script/blob/master/docs/goals_and_design.md)
+* Article on [testing with CLB](TODO: link) is another introduction to testing CEM Script dApps.
 
-Building is performed with cabal.
-Building requires `libblst` and `libsodium` installed.
+## Building
 
-Arch Linux has `libblst` in AUR, nix are exemplified by IOHK,
-and manual installation is described here:
-https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/getting-started/install.md#installing-blst
+Building is performed with `cabal`inside IOG's `github:input-output-hk/devx` shell.
+See `.envrc` for details.
 
 Make sure to `cabal update` before building.
 
-The project uses `github:input-output-hk/devx` to make the development shell. See `.envrc` for details.
-
 ## Running tests
 
-Tests are runned in emulated environment by default.
-
-Just run: `cabal test`.
-
-For development and fast response once could consider `ghcid`.
-
-## Starting local devnet
-
-Tests depend on localdevnet, which is runned in Docker.
-To start it do:
-
-```bash
-./prepare-devnet.sh
-docker-compose  -f docker-compose.devnet.yaml up
-sudo chown -R $USER:$USER ./devnet/
-```
-
-## Devnet stalling bug
-
-Sometimes devnet stalls, due to some bug, in that case one should restart it,
-and wipe directory `./devnet/db`. To look for stalling one could check:
-`CARDANO_NODE_SOCKET_PATH=./devnet/node.socket cardano-cli query tip --testnet-magic 42`. For properly working devnet slots should change
-and sync be marked as 100%.
-
-On this bug:
-https://forum.cardano.org/t/restarting-custom-private-networks-cardano-node-forge35/116921
-
-## Project status
+Tests are runned in emulated environment using
+[CLB](https://github.com/mlabs-haskell/clb).
 
-Project is in early development stage and is funded by
-[Catalyst proposal](https://projectcatalyst.io/funds/10/f10-development-and-infrastructure/mlabs-cemscript-sdk-get-your-dapp-implementation-from-annotated-on-chain-logic-state-machine).
-Detailed milestones of proposal and their status [are available](https://milestones.projectcatalyst.io/projects/1000118) as well.
+Just run: `cabal run cem-script-test`.

docs/catalyst_milestone_reports.md

@@ -10,10 +10,11 @@
 * Final code clean-up:
   * [PR#113 - finalize mutation tests](https://github.com/mlabs-haskell/cem-script/pull/113)
   * [PR#109 - cosmetic changes](https://github.com/mlabs-haskell/cem-script/pull/109)
-* Final tutorial and docs
+* Final tutorial and docs:
   * [PR on docs](https://github.com/mlabs-haskell/cem-script/pull/115)
     * [Getting Started Guide](https://github.com/mlabs-haskell/cem-script/pull/115/files#diff-31bcba2ccafa41d46fbbd6d1219f7f1e3b1fb3cad9faa8e4dc521bbb579dd7b3)
-    * Updated [Goals And Design](TODO: link)
+    * Updated [Goals And Design](https://github.com/mlabs-haskell/cem-script/pull/115/files#diff-ef1a1e144302d41f2687f34dc1885cd8434e6395aa5443c81a2bca8414911972)
+* [Closeout video](TODO: link)
 
 ## Clarifications on M3 Deliverables
 

docs/getting-started.md renamed to docs/getting_started.md

@@ -13,7 +13,7 @@ and demonstrate them by listing specific problems that
 arouse in the existing dApps codebase.
 
 Such problems are specific security vulnerabilities of different
-types. They are still common in development which increases 
+types. They are still common in development which increases
 audit and support costs.
 
 Also, this document describes how existing solutions
@@ -183,7 +183,7 @@ At least three errors of this kind are known in Cardano/Plutus
 interval logic, showing that it is not easy to do.
 
 Another problem is keeping time logic in sync between on-
-and off-chain code. This is even harder given that Plutus' 
+and off-chain code. This is even harder given that Plutus'
 time-to-slot conversion gets in the way.
 Slot time differences and overall need to make test cases match
 real blockchain behavior may lead to flaky test behavior.
@@ -192,7 +192,7 @@ Our script stages abstraction cover all those kinds of problems.
 
 ### Matching to off-chain logic
 
-The problem of duplicating logic between on-chain and off-chain 
+The problem of duplicating logic between on-chain and off-chain
 is twofold.
 Testing is essentially done off-chain, thus, one may easily miss
 that your on-chain code is not actually enforcing some parts of
@@ -256,7 +256,7 @@ for possible utxo changes.
 
 Our project encodes scripts in the form of a deterministic machine,
 which contains enough information to construct transactions automatically.
-This also gives a way to check for potential on-chain 
+This also gives a way to check for potential on-chain
 vs off-chain logic differences semi-automatically.
 
 Examples:
@@ -371,14 +371,14 @@ but only partially covers
 While it, surely, can do transaction emulation,
 it, to the best of our knowledge, does not have a monad instance
 for real L1 blockchain. So one still cannot reuse the same code
-across tests and real blockchain Tx construction.
+across tests and real blockchain transaction construction.
 
 `TxSkel` datatype is similar to the design we are implementing,
 and other parts of API have a lot of cool DX decisions.
 But `cooked-validators` lack script transition model,
 so it cannot provide declarative transaction submission error handling
 we aim to get because it does not have information to decide
-whether a specific Tx input is critical (like an auth token),
+whether a specific transaction input is critical (like an auth token),
 or can be re-selected again (like coin-selected ADA for payment).
 
 Having a declarative transition model is even
@@ -394,7 +394,7 @@ to attack vectors missed by accident.
 
 Our API presumes that means of on-chain validation,
 in our case behavior equivalence (AKA bi-similarity)
-of a declarative CEM state machine and a real on-chain 
+of a declarative CEM state machine and a real on-chain
 script is verified and validated semi-automatically.
 Also, we plan to make some kind of the vulnerabilities covered by
 `cooked-validators` impossible by construction,