What exactly is the role of the cardano-nodes in Daedalus instances in the network?

So, Daedalus runs a full-node, needing lots of disk space and lots of RAM and burning quite a few CPU cycles for it.

Does it do something good for the network in the process? Is it beneficial to the network if I let Daedalus run for extended periods of time?

Or, alternatively, could I use these resources for something more than a simple wallet app? For example, why do I have to query external block explorers and NFT websites for information that, theoretically, already lies around on my hard drive (or USB stick)? Could that data somehow be made accessible?

(I have half-skimmed cardano-db-sync, but if I understood that correctly, it needs at least as much space again on top of cardano-node that is still necessary. There has to be a more efficient way to do this.)

I guess it still contributes by verifying the transactions, but not a protocol expert here, someone else will probably have more detailed info.

cardano-db-sync would probably be a requirement to execute queries on the blockchain data, and using db indexes it’ll be fast, otherwise you would need to traverse the whole blockchain to get an answer for questions like these.

1 Like

I think, my very unfinished idea would be to have an alternative (half-)full node implementation that externally speaks the same protocol, but does not store the whole blockchain, but rather puts (part of) it in an indexed storage on-the-fly, so that I don’t need quite as much space as with cardano-node + cardano-db-sync (ideally only a little more than cardano-node for the full information and even less if I can configure to store less than everything).

But I probably would need a very good documentation of the protocol for that.

1 Like

Or enough spare time to research the db-sync haskell sources ;D

Edit: dismiss my message above, you meant “alternative (half-)full node implementation” :slight_smile:

1 Like

I’m a theoretical computer scientist with an extensive background in category theory, but still didn’t get the drive to learn me Haskell for a great good. :grin:

Extracting knowledge about the protocol from cardano-node instead of cardano-db-sync would be a totally equivalent endeavour.

An “Anatomy of the Cardano Network” deep dive, that is neither only the mathematics (like the academic papers) nor “copy these to the shell to get a node running (even if you don’t know shit about Unix/Linux)”, but a bit-exact walk-through what happens on the network, would really be nice.

1 Like

cardano-db-sync is basically just a postgres database with ingestion from the blockchain ledger. You still need a relay node for network, syncing, etc as the source of truth. Running both on an average server or locally on a development machine is simple enough. While db-sync doesn’t have all the data that exists on-chain it is at least in a nice relational format to easily use SQL which is something almost every developer is familiar with … sorry haskell, but you barely make the top 50 list :wink:

That said disk usage is not a primary concern in an age where the internet generates gigabytes of data every second. Analyzing and actually using it has become the focus so if you wanted to craft a more efficient method of indexing and searching blockchain data that would be a pretty cool project. Most blockchain explorers probably are just slapping elastic search, graphql, or other existing solutions on top of using cardano-db-sync as an aggregate storage cache for performance.

1 Like

Yes and Yes.

It helps propagate newest blocks faster around the world. It reduces network lag as well as reduction in ghosted blocks. All this also prevents the network from wasting resources on forking branches that will get ghosted.

Also, it helps stake pools to not miss their chance to produce a block due to ghosting.

1 Like

As I see a lot of discussion on topology updater and making pool relays publicly announced or not: Does it make sense to monitor the Daedalus node with gLiveView and to try to optimise its connections for that task?

I suppose it would add more value if it connected to pool relays/nodes that would be far away in the topology, otherwise? Connecting to two nodes that have a direct connection, anyway, doesn’t help much, does it?

On the one hand, yes, probably. On the other hand, we already have desperate questions, here, how to put it on external storage (I had to do it, because my SSD was a bit short on free space, myself). And the RAM and CPU usage is definitely a concern.

And this might rapidly become a growing problem if Cardano gets adopted more. Bitcoin’s blockchain is already over 375 GiB (and they don’t even have NFTs and contracts/scripts on there, probably Ethereum is bigger already).

I tend to think that storing the whole history only works, as long as only a tiny minority of the people use it and they don’t use it for day-to-day things, but just for investment (or what they think is “investment”, NFTs and stuff).

Storing every grocery shopping transaction of the whole world population forever on every stake pool node, let alone every Daedalus installation, would be ridiculous pretty fast.

There has to be a solution, where irrelevant parts of the history can be thrown away by everybody (except maybe a handful of archive nodes) and maybe also, where not every node has to verify every transaction.

gLiveView is just a standalone monitoring tool. Not sure how using that relates to chain propagation.

All nodes have peers. I believe it was because Cardano network chose to not use broadcast system the path of nodes made the most sense. This way having more nodes would allow network to reach their goals of 95% of propagation in 5 second or under. This way it also saves network resources by not having to broadcast to all nodes, just peer nodes. Peers then make a path trough a whole network facilitating propagation of newest chain. The flow looks something like this:

No, it actually does not. Daedalus does not validate blocks (only block producer nodes from stake pools do). Therefore, the node is only used to submit transactions and lookup the wallets balances and transactions.

There are no benefits for the network if you run the node for Daedalus - it just stresses the infrastructure of IOHK because it services your node with updates (new blocks) on the chain.

No one here claimed that Daedalus produced blocks.

No it does not, because Daedalus (by default) only connects to IOHK relays, and it only pulls blocks and does not produce anything. In other words the node of Daedalus is 100% passive and does not participate in any way with the network, but only IOHK nodes.

1 Like

Without producing blocks it does not make sense to participate actively with the network. In other words Daedalus does nothing but pulling blocks from IOHK nodes.

Cardano nodes have only one peer: IOHK, and thus do not actively participate in the network.

Quote from Cardano (dot)org Daedalus Wallet docs::

  • Trustless operation with locally running full Cardano node which independently validates full transaction history of the blockchain
  • Supports Cardano network by participating in Cardano protocol


Participating in the protocol only means connecting to IOHK relays. That adds nothing to the network. And sure, in order to display only correct transactions it has to validate the blocks. But it does not send the results of this validation anywhere. Because information about blocks is pulled and not pushed. And, btw. every node does that validation - i.e. there’s no reason to send the result of the validation.

The node software is the same as on relays or block producers, just configured differently. The only support to the network is, that is holds a copy of the blockchain.

You are reading something into the wording that does not exist.

I was thinking to monitor, how it is connected, but:

If only IOHK relays are hard-coded in there, that does not make much sense. Could I configure it to connect to other relays to reduce stress on IOHK and become more decentralised? Would that even make sense or be a good thing?

That it does not produce, was clear to me. It’s not a pool. But it could forward blocks from others (don’t know if that could make sense for the network topology, would add delay, but also could perhaps reduce the necessary connections for the pools) and it could validate and propagate its validation assessment.

But, at the moment, that all can already not happen (besides not being implemented), because blocks are only pulled, not pushed, and a Daedalus instance can most often not have any incoming connections, because people use it behind their home routers without forwarding the port, right?

Well now you got it. There’s no incoming connections, because it does not (should not!) act as a relay. Connecting only to IOHK relays is no problem - they provide the infrastructure for Daedalus. Other wallets are using different ways to do their job - and AFAIK don’t run a full node on the client side.

Connecting Daedalus to relays of stake pools is not that much of a good idea because it ads load to their relays which might become an issue if it is done in masses.

It’s literally in design papers that full node wallets remove backpressure of diffusion layer by using local resources to retry failed transactions when network demand is high. Thus, providing a support for diffusion layer. Also, making some levels of network congestion not an issues for full node users, as can be seen during some of the NFT drops.