What exactly is a participant node?

G-d willing

Hello,
I can’t seem to fully understand what exactly is a participant node. Is it hardware based, a software which the ledger API speaks to? Or is it a combination of the two?

Hi @cohen.avraham :wave: and welcome to the Daml developer forum :slight_smile:

In short, a participant node exposes the Ledger API that in turn talks to the underlying database or a network. You need to set up infrastructure (hardware) for it to run on.

Does this help?

1 Like

Hi @nemanja, thanks for your quick reply :ok_hand:.
So how does it work along with the JSON API?
According to my understanding, the JSON API and the Ledger API are physically installed on the same server. (Or maybe it isn’t?) So why is the Ledger API needed to be exposed to the JSON API by this “participant node”? Why can’t it speak directly to it?
I understand that technically the JSON API is not required in a solution, and I actually can implement my own layer which will speak directly to the Ledger API. So does it mean that the Ledger API cannot be accessed directly by users? Which means that the participant node is a software layer which does all the communication for us with the Ledger API?

1 Like

Hi @cohen.avraham,

You can access the Ledger API in different ways, JSON API being one of them. From the docs:

You can access the Ledger API via the HTTP JSON API, Java bindings, Scala bindings or gRPC. In all cases, the Ledger API exposes the same services

Note that Scala bindings will soon be deprecated.

So does a Participant Node is basically the physical server in which the Ledger API is installed on?

2 Likes

Spot on :ok_hand:

1 Like

Thank you very much @nemanja :+1:

1 Like

To clarify a bit: “participant node” is anything that exposes the gRPC Ledger API. From a client perspective, it’s basically an IP address, a port, and a promise that we can make a gRPC connection to it and expect it to understand the messages defined by the Ledger API spec.

There are many different implementations that could be the server behind that IP & port, and “participant node” is the generic term for them.

The JSON API is a normal (gRPC) Ledger API client. It is not special in any way; anyone could have written it, it can run on a separate server, etc. It happens to be a component we provide because it seemed to fit a relatively common use-case, but ultimately it’s not part of the core ledger model and it’s not more special than any application you would write against the (gRPC) Ledger API.

You could imagine a setup where the JSON API runs on the same server (or within the same internal network) as the (gRPC) Ledger API, and where the JSON API is the only one exposed “outside” that server/internal network. That’s a valid choice, though one in which you should remember that the JSON API does not expose the full power of the Ledger API, so clients that are forced to only go through it will be somewhat restricted in what they can do.

3 Likes

Thank you very much @Gary_Verhaegen for your detailed explanation.