intersectmbo / cardano-node Goto Github PK
View Code? Open in Web Editor NEWThe core component that is used to participate in a Cardano decentralised blockchain.
Home Page: https://cardano.org
License: Apache License 2.0
The core component that is used to participate in a Cardano decentralised blockchain.
Home Page: https://cardano.org
License: Apache License 2.0
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.
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
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).
Caused IntersectMBO/ouroboros-network#1106 when consensus changed slot number format.
This will create one connection per core node, but they will all be towards "Core node 0".
cross-compilation towards "mingw32" had to be disabled temporarily due to dependence on package unix
.
needs some cleanup also in the libraries..
After a while, Updated chain:
logs are spanning across multiple screen (wrapped).
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:
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)
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).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.
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 🙂.
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:
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.
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:
a1
, b1
and c1
and send transactions to all three nodes (sequentially or randomly).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.
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:
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
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 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).
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.
Continuation on #96 we update the dependencies.
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
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.
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.
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).
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.
We want cluster-based integration tests for the node.
cardano-sl
cluster startupcardano-byron-proxy
test:
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
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
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.
--
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.
cardano-node
as NixOS servicechairman
as a NixOS service, so it can be integrated with the abovechairman
as a check against the said clusterchairman
's pass/failure criteria, so they are a useful measure of regressiondefinition of chain quality (named density
):
|blocks| / |slots|
tracing and monitoring of chain quality:
(request by @disassembler)
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")
Part of #30
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.
demo-playground
is a simple implementation of a node. Once this is mature enough this needs to be moved to cardano-node
.
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.
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))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
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
We need means to manipulate secrets/certificates/genesis files (henceforth referred to as key material).
Bi
instance for the legacy UserSecret
data typeSigningKey
.vssCerts
from the top level,vssMaxTTL
and vssMinTTL
from the protocolConsts
sectionDELEGATE-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.
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.
cardano-binary
uses in the Bi
typeclass is CBOR, which means there's only a thin compatibility layer that needs to be reimplemented.GENESIS-INCOMPATIBLE-BYRON-LEGACY-PBFT
: Byron Legacy carries the VSS certificates, which aren't generated by the Byron PBFT genesis generator.
When using dnsSubscriptionWorker
cardano-node
should support both IPv4 and IPv6 addresses.
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).
iohk-nix
:: The "standard library" of IOHK-specific Nix code intended to simplify usage of haskell.nix
by the IOHK client repositories.cardano-ledger
, ouroboros-network
and cardano-node
.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.
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.
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".
Due to systemic nature of the problem, one would expect that this would require dedicated expert effort the DevOps team.
QA team to develop test plan & test coverage for the re-write node
based on new version of iohk-monitoring-framework
(epic: input-output-hk/iohk-monitoring-framework#277)
--tracing-verbosity-minimal
--tracing-verbosity-normal
(the default)
--tracing-verbosity-maximal
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
The node currently will take ~2 weeks to sync vs ~3 days for cardano-byron-proxy
. The node needs to be profiled.
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:
cardano-sl
.cardano-node
, ouroboros-network
& potentially cardano-byron-proxy
.When building cardano-node there are various warnings, we should address them and turn on -Werror
on CI.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.