Skip to main content

Publisher

Publishing the subjects

The role of Publishers is to publish streams of data to the Broker network. A stream of messages has to have a subject, which is basically its name. The goal is to create an open and competing market for Publishers, therefore, there is no limit to the subjects that Publishers can publish.

An example of a subject is syntropy.ethereum.*, where syntropy is the name of the entity, i.e. Publisher’s owner, and ethereum is the name of the Publisher’s App. A single subject might have multiple tokens after these two initial prefixes, such as syntropy.ethereum.txs and syntropy.ethereum.logs.

Broker network is based on the messaging technology called NATS. In NATS terminology, tokens are words between the dots. Two wildcards, * and >, can be used to denote complex multi-token subjects. For instance, subject entityname.appname.swap.> would automatically enable a stream with multiple subtopics in the form of entityname.appname.swap.weth.usdt and entityname.appname.swap.usdt.weth that provide sorted transaction-based token swap pairs.

Read more about subject construction in NATS documentation and our official guide on how to run a Publisher.

Registering the services

Publisher subjects are registered on a chain and each subject is backed up by credit. This happens on the developer portal registration process. A service is an on-chain agreement between the Publisher and its Subscribers, which contains the price of data sent under the subject as well as other crypto-economic variables that ensure that the decentralized agreement is being fulfilled.

After the service is expired by the Publisher, and all the accounting rounds related to it are completed, the credit is returned to the Publisher.

Subjects are priced according to the service agreement. The service is accounted for in bytes and priced per some fixed number of bytes of data, e.g. 1 gigabyte. In theory the pricing could be designed to be per message, however, there are three main reasons why pricing and accounting per bytes were chosen:

  1. Broker network costs are inherently attached to the number of bytes relayed.
  2. Bytes are a common denominator of all data, the pricing between various Publishers is then easier to compare.
  3. Subscribers prefer more sustainable Publishers, who can put the same information in a leaner format because it is cheaper to consume and saves Brokers’ bandwidth as well.

Trust assumptions

In the tokenomics v1, the trust of the Publisher has to be taken into account by each Subscriber when subscribing to its subjects. This is exactly the same as the currently existing setup in the RPC node market: clients are purchasing blockchain data from RPC node providers they trust.

Publisher exit

When a Publisher wants to exit the Data Layer economy, it would naturally seek to retrieve the tokens it has credited on the chain. However, this requires that all its services are expired and removable. Since the Publisher’s ability to expire the service depends on the demand for the service, the whole exit process can take some time. However, free-of-charge data streams can be closed much faster.

Future work

caution

All future work is the research and development that is planned, however, this cannot be seen as a commitment to deliver certain features.

Trustless Publishers

In the future version of the Synternet Data Layer protocol, the access to published data should be trustless. This would require that multiple Publishers provide exactly the same data. Within such a setup, the Publisher’s credit has a future use, as it can be slashed if the Publisher fails to send data or sends corrupted data. Additionally, this feature would also improve the exit flow for any individual Publisher who is just one of many sources for the same data.

Credit-based publishing rate

The Publisher’s credit can be used as a limiting factor for the publishing rate: the more bytes per second a Publisher wants to push through the Broker network, the more tokens it has to credit. This puts some constraints on Publishers in how they construct their data streams: more data is not always desirable when the same information can fit in a smaller message. Pushing useless data through the network should be avoided when possible, and this would help to mitigate spam.

Credit delegation to the Publishers

A possible improvement of the Data Layer protocol would be enabling token delegation to the Publishers. In such a way, Publishers would be able to share some of the profits with their investors. Publishers themselves would profit from more credit bonded to them, as it would allow them to publish more subjects and/or publish at a higher rate (more bytes per second) in general.