Continuation on #96 we update the dependencies.

• Done - IntersectMBO/ouroboros-network#616

When building against the latest master in ouroboros-consensus:

[ 7 of 10] Compiling TxSubmission

/home/nc/topos/iohk/cardano-node/app/TxSubmission.hs:228:27: error:
    • Could not deduce: Block.HeaderHash blk ~ Block.ChainHash block0
      from the context: (RunDemo blk, MonadST m)
        bound by the type signature for:
                   localChainSyncCodec :: forall blk (m :: * -> *).
                                          (RunDemo blk, MonadST m) =>
                                          NodeConfig (BlockProtocol blk)
                                          -> Codec
                                               (ChainSync blk (Point blk))
                                               DeserialiseFailure
                                               m
                                               ByteString
        at app/TxSubmission.hs:(219,1)-(223,42)
      Expected type: Block.HeaderHash blk -> Codec.CBOR.Encoding.Encoding
        Actual type: Block.ChainHash block0
                     -> Codec.CBOR.Encoding.Encoding
      The type variable ‘block0’ is ambiguous
    • In the first argument of ‘Block.encodePoint’, namely
        ‘(Block.encodeChainHash demoEncodeHeaderHash)’
      In the third argument of ‘codecChainSync’, namely
        ‘(Block.encodePoint (Block.encodeChainHash demoEncodeHeaderHash))’
      In the expression:
        codecChainSync
          (demoEncodeBlock pInfoConfig)
          (demoDecodeBlock pInfoConfig)
          (Block.encodePoint (Block.encodeChainHash demoEncodeHeaderHash))
          (Block.decodePoint (Block.decodeChainHash demoDecodeHeaderHash))
    • Relevant bindings include
        pInfoConfig :: NodeConfig (BlockProtocol blk)
          (bound at app/TxSubmission.hs:224:21)
        localChainSyncCodec :: NodeConfig (BlockProtocol blk)
                               -> Codec
                                    (ChainSync blk (Point blk)) DeserialiseFailure m ByteString
          (bound at app/TxSubmission.hs:224:1)
    |
228 |       (Block.encodePoint (Block.encodeChainHash demoEncodeHeaderHash))
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

As a end user, I would like to see the db dir named just db and the socket file named node.socket. Currently this is db-0 and node-core-0.socket. The only reason for running more than one node on a system is for tests and demos, so I don't see the reason for this extra addition of an index to all the directories.

QA team to develop test plan & test coverage for the re-write node

We need to support staking-related scenarios in CLI tooling, as per Chapter 4 of https://hydra.iohk.io/build/902246/download/1/delegation_design_spec.pdf

This is part of #30

The staking scenarios

0. Stake Pool Registration:
   • manipulation of pool metadata and stake pool registration certificate.
   • submission to the blockchain
   • status queries
1. Querying of the active stake pools (and of their metadata).
2. Delegation support:
   • staking key registration and delegation certificate manipulation
   • submission
   • querying the delegation status
3. Individual staking, which seems to be a variation of the above procedures.

Implementation

Continuing with the established trend, cardano-node will be acting as a validator and the block chain agent, whereas the cardano-cli will deal with forming of the data blobs and generally the UI for the above operations.

The communication between cardano-node and cardano-cli is expected to be at least partly formulated in terms of generalised transactions, but with extensions, since the extended metadata queries, such as for state of pool/staking key/delegation.

An important parallel development is a sister update system node-to-client protocol, which is expected to share a similar structure (generalised transactions + extended status queries).

Dependencies

1. We need proper generalised transaction support for transactions beyond just UTxO expenditures. This is being worked on in IntersectMBO/cardano-ledger#623

Currently live view can be stopped by q or Q key. But after TUI thread is stopped, node continue work. We want to change this behavior, @coot said:

When one hits q to kill a node with running live view it only kills the live view, I think it's okay to just kill the node as well. Somewhat related issue: it seems that live view is capturing signals, one cannot kill it with CTRL-C.

• Done - IntersectMBO/ouroboros-network#534

The following TODO can be resolved as IntersectMBO/ouroboros-network#1032 has been merged: https://github.com/input-output-hk/cardano-node/blob/3276f8b115cd802828cff36f7291cffa3a9f393e/cardano-node/src/Cardano/Tracing/ToObjectOrphans.hs#L663
Now, it just traces ChainSyncServerEvent, which is pretty useless 🙂.

definition of chain quality (named density):

|blocks| / |slots|

tracing and monitoring of chain quality:

• threshold?

(request by @disassembler)

When building cardano-node there are various warnings, we should address them and turn on -Werror on CI.

The node currently will take ~2 weeks to sync vs ~3 days for cardano-byron-proxy. The node needs to be profiled.

1. Adding CLI for full proper Tx specification (so elaboration isn't needed) -- basically 1) source-signing key, 2) dest addresses, 3) amounts Out of scope -- we just need to submit signed Tx blobs.
2. Input validation -- amounts matching (there is probably library code in the ledger for this?) -- nothing else? Node does validation and will respond with error.
3. Moving some code (since tx submitter doesn't belong to the node)
4. Tests (out of scope here). Supposed to be a separate major effort to add a full-loop integration test with cluster creation, Tx submission and ledger querying.

Part of #30

The pvss package was needed in the old codebase as part of the Ouroboros Classic implementation.

The new codebase does not implement Ouroboros Classic and thus does not use the SCRAPE VSS scheme. We still have a dependency on the pvss package however, but this should be dropped.

It is used in two places:

1. src/Cardano/CLI/Legacy/Byron.hs where the LegacyDelegateKey contains a lrkVSSKeyPair :: Scrape.KeyPair. This key pair appears to be unused (which is good, there's no use for it). The old binary format contained these things, so we still need to be able to decode the old format, but we do not need to store the result. So we do not need the KeyPair type imported from Crypto.SCRAPE

2. src/Cardano/CLI/Ops.hs where the only use is Scrape.keyPairGenerate which is used to fill in the lrkVSSKeyPair as part of encodeLegacyDelegateKey. But if this member is removed then it does not need to be generated. The encoder could use dummy values to keep the same legacy format because they will never be used.

I think this repo is in dire need for some clean up. We have been focussing too much on adding as much as we can in a short time, without thinking about the long term.

Examples:

• Most code lives in the executable folder app/ instead of the library folder cardano-node. IMO, app/ should just contain a single file Main.hs containing:

  module Main (main) where
  import  Cardano.Node.Main (main)

  The genesis-tool even lives inside this directory! I expect this is because it depends on the code in the app directory. It should live in a separate directory containing a similar Main.hs file (or only containing minimal code).
• We should extract code in helper functions and/or separate modules, e.g., https://github.com/input-output-hk/cardano-node/blob/e42d7396f77e24b03379bc61f668ab526a0e062d/app/Run.hs#L258-L416, this is just making this file way too long and unreadable (I'm guilty of these tings myself).
• In the scripts folder, there are too many demo scripts, some of which are not working anymore. The numbering might also make people think they match the demos that we gave, which is untrue.

Also, synching the different dependencies (cardano-ledger, ouroboros-network, ..) has been an endless time sink so far: to update the dependency on A, we often need to first get a PR updating the dependency on A merged in B before we can do it in cardano-ledger (we can't submit two PRs at once, because the hashes will change and have to be updated after the merge). These PRs quickly go stale or are stalled until someone that made some breaking change can help fix it.

After a while, Updated chain: logs are spanning across multiple screen (wrapped).

Currently it's possible to generate transactions with input(s) and output(s) only, so it's the simplest case. We need to add an ability to increase the size of transactions not by increasing number of inputs/outputs, but by adding additional binary blob. This will allow us to generate really big transactions, to get more real-life benchmarking results.

I think the scripts in scripts could be better documented in the README.md or maybe a separate SCRIPTS.md file. This will also help in removing scripts we no longer need.

Context

We want cluster-based integration tests for the node.

Current scope (to be extended)

1. Cluster consensus validation: #106
   • status: implementation mostly done
2. Extend to mixed cluster of old and new nodes, in PBFT era/mode, both producing blocks, connected via proxies: #255
   • status: stuck debugging cardano-sl cluster startup
3. cardano-byron-proxy test:
   1. Basic functionality
   2. Heap profiling
   3. Strictness check using @edsko 's WHNF checker.
4. Cluster Tx submission

Implementation

NixOS tests that can run a cluster in a VM are a good foundation for many of those.

This basis functionality was merged in #177

Currently tx generator is able to connect to one single node (of the cluster) and send transactions to this node only. It would be useful to be able to send transactions to multiple nodes in the cluster (because it's more real-life case).

There are two possible ways how to do it. For example, if we have a cluster from 3 nodes (a1, b1 and c1), we could:

1. run one instance of tx generator with an ability to connect to a1, b1 and c1 and send transactions to all three nodes (sequentially or randomly).
2. run multiple instances of tx generator, for example tx_gen_a1, tx_gen_b1 and tx_gen_c1, so tx_gen_a1 will send transactions to a1, tx_gen_b1 - to b1 and tx_gen_c1 - to c1.

AFAIU, the first way is assuming some changes in the tx generator's code. The second way is assuming some changes in cluster's configuration.

Currently transaction generator is able to produce transactions with one single input only. We have to add configurable ability to generate transactions with multiple inputs.

• Done - https://github.com/input-output-hk/cardano-shell/milestone/11

Goal

This is a subgoal of #211

We want an integration test for the Legacy/OBFT to Shelley/OBFT transition phase.

This means that we want to run a cluster configuration with two segments -- nodes running cardano-sl and nodes running cardano-node -- with having a number of cardano-byron-proxy connecting those.

Implementation

The entire cluster is supposed to run in a NixOS test on a single machine, to lighten load on CI & make the test faster.

The cluster has to share the same genesis, for obvious reasons, so cardano-sl nodes must use external genesis. Preferably we should use a genesis with configuration as close to mainnet as possible (to make the testing maximally relevant).

Deliverable

The final PR that enables this functionality is #269

Based on input-output-hk/cardano-shell#238, this issue is all about moving the configuration-specific parts of cardano-shell into the node.

The CLI tools in this repo currently rely on the cryptonite-openssl package for getting entropy for the purpose of creating crypto key pairs. This should be replaced by the equivalent functionality from the cryptonite package.

The OpenSSL version is designed to allow a high volume of random entropy to be generated in a reasonable way (e.g. for use in TLS). This is not a requirement we have, since we only use it in CLI tools for generating key pairs, which is very low volume. So it is acceptable to use the functionality in cryptonite which just gets randomness direct from the OS (/dev/random on unix, equiv on Windows).

the node starts afresh and syncs blocks over the network. Once it reaches 60 minutes of CPU time the process is killed and logs analyzed.
we note:

• the time a block is included in the immutable store ("CopiedBlockToImmDB")
  additionally, we collect counters every 30 seconds:
• network read/write bytes
• I/O read/write bytes
• memory usage
• CPU usage

When using dnsSubscriptionWorker cardano-node should support both IPv4 and IPv6 addresses.

Context

We need means to manipulate secrets/certificates/genesis files (henceforth referred to as key material).

General scope

0. Generation/derivation of all sorts of necessary key material.
1. Support for all necessary iterations of the system -- Byron and Shelley for now, the former in both the Legacy and PBFT variants.
2. Support for migration of key material between iterations of the system.
3. Transaction manipulation and submission.
4. Update system support.
5. Support for delegation & staking.

Terminology: Legacy vs. PBFT

• delegator :: Genesis keys. Referred to as delegation issuer keys in Legacy.
• delegate :: Operational keys of core nodes used for block minting and proposal signing. Referred to as richmen keys in Legacy.
• VSS :: Publicly Verifiable Secret Sharing Scheme algorithm used in Ouroboros Classic/Byron Legacy.

Future work

0. More transaction-related things: creation, pretty-printing.
1. Update system:
   • stimuli (proposals and votes): creation, pretty-printing, submission.
   • querying the node for the update system state.
2. Staking (#139):
   • stake pool lifecycle
   • lightweight delegation

History of implementation

#28

0. Generation of key material (genesis, keys) for new Byron Legacy clusters.
1. Generation of key material (genesis, keys) for new Byron PBFT clusters.
2. Migration of Byron Legacy key material (genesis, keys) to the Byron PBFT iteration. So far this appears to consist of:
   • Deserialisation of the delegate keys in the old format, as defined by the Bi instance for the legacy UserSecret data type
   • Reserialisation of the delegate keys in a new format, which, while not yet decided, has a candidate format of just a CBOR serialisation of SigningKey.
   • Cutting VSS out of the genesis file:
     • vssCerts from the top level,
     • vssMaxTTL and vssMinTTL from the protocolConsts section
3. Pretty-printing of the key material.

#95

0. Separate, non-genesis keypair generation for Byron/PBFT.
1. Non-HD address printing for a given keypair.
2. Genesis hash printing.
3. Byron genesis delegation: generating delegation certificates for a given pair of genesis/delegate keys.

#135 & #147

0. Raw TX submission over local node submission protocol.
1. Genesis UTxO expenditure.

Notes

• DELEGATE-SECRETS-INCOMPATIBLE-BYRON-LEGACY-PBFT: as @dcoutts mentioned

  VSS, the Ouroboros classic randomness MPC algorithm, is not used after the PBFT hard fork.

  Therefore, the delegate secrets will no longer contain the VSS keypair, which makes them incompatible between the Legacy and PBFT iterations of Byron. This needs to be accounted for with regards to both the generation and migration aspects.

  • The compatibility was implemented in the new codebase.

• SECRET-SERIALISATION-INCOMPATIBLE-BYRON-LEGACY-PBFT: Byron Legacy is using cardano-binary for secret serialisation, whereas Byron PBFT uses CBOR. This needs to be accounted for with regards to both the generation and migration aspects.

  • This does no longer appear to be a problem, since the underlying encoding that cardano-binary uses in the Bi typeclass is CBOR, which means there's only a thin compatibility layer that needs to be reimplemented. The thin compatibility layer for Byron Legacy delegate key roundtripping was reimplemented.

• GENESIS-INCOMPATIBLE-BYRON-LEGACY-PBFT: Byron Legacy carries the VSS certificates, which aren't generated by the Byron PBFT genesis generator.

Terminology

• iohk-nix :: The "standard library" of IOHK-specific Nix code intended to simplify usage of haskell.nix by the IOHK client repositories.
• client repository :: repositories using the IOHK Nix infrastructure, such as cardano-ledger, ouroboros-network and cardano-node.

The problem

After the initial introduction of iohk-nix into the build machinery of IOHK's Haskell-code-carrying repositories grew, these repositories started inevitably diverging -- that is, accumulating local, repository-specific Nix changes, extending the functionality provided in iohk-nix.

Some of those extensions are truly repository-specific, but not all are -- some extensions are conceptually repetitions of the same thing from the other repository, and so they contribute to the overall complexity of the system in an excessive way.

Proposed solution

Overall, we should revisit the way how the repository-specific Nix build system extensions are defined -- with the aim of making it as minimal and declarative as possible.

To do this effectively, we would need to perform a systematic review of what Nix extensions are defined in the client repositories, for what purpose, and based on that picture, define a more declarative and comprehensive interface between iohk-nix and client repositories -- and then implement that across all of IOHK repositories.

Time frame

This is not an immediate problem, but rather one of the sort that reduces the overall efficiency of the development process.

This appears to define the planning horizon for this work as vague "middle-term".

Development resources

Due to systemic nature of the problem, one would expect that this would require dedicated expert effort the DevOps team.

hydra failed to build the project for target OS MacOSX/Darwin.

diff --git a/release.nix b/release.nix
index ef25628..f92c98e 100644
--- a/release.nix
+++ b/release.nix
@@ -44,9 +44,9 @@ iohkLib.nix-tools.release-nix {
   required-name = "cardano-node-required-checks";
   required-targets = jobs: [
     # targets are specified using above nomenclature:
-    jobs.nix-tools.libs.cardano-node.x86_64-darwin
+    #jobs.nix-tools.libs.cardano-node.x86_64-darwin
     jobs.nix-tools.libs.cardano-node.x86_64-linux
-    jobs.nix-tools.exes.cardano-node.x86_64-darwin
+    #jobs.nix-tools.exes.cardano-node.x86_64-darwin
     jobs.nix-tools.exes.cardano-node.x86_64-linux
     jobs.nix-tools.tests.cardano-node.cardano-node-test.x86_64-linux

the calculation of chain density (#250) makes the assumption that the length of an epoch depends on the parameter k = 2160 (10x in Byron). In case of Praos, epochs will likely be shorter.

TODO in cardano-node/src/Cardano/Tracing/Tracers.hs#L186

This is a reminder that this will not be the case in Shelley and so the code needs to be adapted.

On commit 70ee53469b:

$ nix-build -A scripts.mainnet.node
$ ./result
cardano-node: user error ("Unspecified ccSocketPath")

https://github.com/input-output-hk/cardano-node/blob/070cb238baa176a3f9011b3f0c60ea0c901f41ce/cardano-node/src/Cardano/Chairman.hs#L114

This will create one connection per core node, but they will all be towards "Core node 0".

based on new version of iohk-monitoring-framework
(epic: input-output-hk/iohk-monitoring-framework#277)

control verbosity

--tracing-verbosity-minimal
--tracing-verbosity-normal (the default)
--tracing-verbosity-maximal

switch textual representation / structured logging

by default, structured logging is turned on: the rendering of the captured observables is controlled by their ToObject instances.

--trace-chain-db turns on textual representation in the ChainDB tracer

1. Describe clusters of cardano-node as NixOS service
2. Describe chairman as a NixOS service, so it can be integrated with the above
3. Define a NixOS test running chairman as a check against the said cluster
4. Tune the chairman's pass/failure criteria, so they are a useful measure of regression

1+2+3 were done in #177
4 is being worked on in #201

I am not sure how this slipped through CI, but I get a type error in cardano-prelude. I am building current master (b9ffe10)

cabal build exe:cardano-node
Build profile: -w ghc-8.6.5 -O1
In order, the following will be built (use -v for more details):
 - cardano-prelude-test-0.1.0.0 (lib) (first run)
 - cardano-binary-test-1.3.0 (lib) (configuration changed)
 - cardano-crypto-test-1.3.0 (lib) (configuration changed)
 - cardano-ledger-test-1.3.0 (lib) (configuration changed)
 - ouroboros-consensus-0.1.0.0 (lib) (configuration changed)
 - cardano-node-3.0.1.87 (lib) (configuration changed)
 - cardano-node-3.0.1.87 (exe:cardano-node) (configuration changed)
Preprocessing library for cardano-prelude-test-0.1.0.0..
Building library for cardano-prelude-test-0.1.0.0..
[3 of 9] Compiling Test.Cardano.Prelude.Golden ( Test/Cardano/Prelude/Golden.hs, /home/marcin/r
epos/iohk/cardano-node/dist-newstyle/build/x86_64-linux/ghc-8.6.5/cardano-prelude-test-0.1.0.0/
build/Test/Cardano/Prelude/Golden.o ) [Hedgehog.Internal.TH changed]

Test/Cardano/Prelude/Golden.hs:119:15: error:
    Not in scope: ‘confTrailingNewline’
    |
119 |             , confTrailingNewline = False
    |               ^^^^^^^^^^^^^^^^^^^
cabal: Failed to build cardano-prelude-test-0.1.0.0 (which is required by
exe:cardano-node from cardano-node-3.0.1.87).

• Done - IntersectMBO/ouroboros-network#585

We just need to improve the naming and add some comments to make this a bit more clear for others who can do the same thing on their part.
This part of the work is being done in an actual node.

logging configuration has been kept in its own Yaml file.
now, we want to integrate this configuration into the node's configuration file (also Yaml format).

the key logging-config (valid name?) shall contain the logging configuration.

the iohk-monitoring framework has read the Yaml into an internediary representation: https://github.com/input-output-hk/iohk-monitoring-framework/blob/master/iohk-monitoring/src/Cardano/BM/Data/Configuration.lhs#L41
and starting from this, built up configuration: https://github.com/input-output-hk/iohk-monitoring-framework/blob/master/iohk-monitoring/src/Cardano/BM/Configuration/Model.lhs

• Done - IntersectMBO/ouroboros-network#609

At the moment it's not clear weather all the arguments for tx submission are really needed. If it's not possible to keep a minimal set of arguments to construct transactions for various protocols, we could submit raw transactions instead of elaborating mock transactions to real ones.

Note: this issue is just to record the problem, not to suggest the right solution.

cross-compilation towards "mingw32" had to be disabled temporarily due to dependence on package unix.
needs some cleanup also in the libraries..

https://github.com/input-output-hk/cardano-node/blob/5e301e0d9fef58033a0aef10b4930473572b1235/cardano-node/src/Cardano/Tracing/Tracers.hs#L186

Caused IntersectMBO/ouroboros-network#1106 when consensus changed slot number format.

Subtask of #255

cardano-node is being extended with configuration file support -- but that functionality is not yet complete. We'll need that at least to configure the slot length for the Mixed Cluster CI.

Once that functionality is ready in cardano-node, we'll need to integrate that mechanism into the Nix expressions defining the cardano-node service.

This is a subtask of #255

We need cardano-sl, cardano-byron-proxy and cardano-node to agree on the same epoch and slot lengths.

This includes:

1. Configuration changes for cardano-sl.
2. Code changes for cardano-node, ouroboros-network & potentially cardano-byron-proxy.

Subtask of #255

Slot length is currently hard-coded in ourobboros-network to 20s [1], which is counterproductive for short CI runs, that would benefit from 1s slots.

--

1. https://github.com/input-output-hk/ouroboros-network/blob/master/ouroboros-consensus/src/Ouroboros/Consensus/Node.hs#L188

• cleanup schema
• list of commands: one per line
• submit-tx script with correct cmd line args

demo-playground is a simple implementation of a node. Once this is mature enough this needs to be moved to cardano-node.

And check if the tips of immutable chain agree. It could be a single client which connects to each node and checks if the three nodes agree.

The current tip is tracked here: https://github.com/input-output-hk/cardano-node/blob/e3d8bea2c151d80b422c9839965c406e83533841/app/Run.hs#L226