Broker
Broker crediting
A Broker entity must register its on-chain profile and is required to credit a predefined amount of Synternet tokens. A free-loader is a Broker entity that is interested only in receiving access to public streams for “free”. Hence, the credit must be high enough to discourage free-loaders from registering as Brokers. But at the same time, it must be sufficiently low in order not to create an artificial barrier of entry to the Broker network.
Broker network and nodes
Broker network is a NATS supercluster, where each Broker entity is responsible for its own cluster of Broker nodes. A set of bootstrap nodes can be added by a Broker entity to its on-chain profile.
Broker nodes in a single network are interchangeable, all nodes have access to all data streams and they are sharing the data within their internal network. When nodes validate each other, they also check for the corresponding entity on the App Chain: it must be registered and sufficiently credited, only then a Broker node may accept another node’s connection.
Broker entities are not limited in the number of nodes they can add to the network. This enables Brokers to respond in a dynamic manner to increased network usage. However, this might change in the future as the network matures.
Currently the staking requirement is per Broker entity, not per Broker node, but this could also change in future versions of tokenomics.
Service selection
Clients connect directly to Broker nodes based on the NATS internal peer-to-peer logic, where the latency between a Client and a Broker node plays a part. This Broker node then automatically becomes the accountant of that stream of data resulting from a particular Client consuming that particular service.
If the Broker node that is delivering the data stream goes offline, the Client will connect to another Broker node. However, in such a case, the accounting session with the old Broker node has to be finished in order for a new accounting session to start. A Client may experience some small delay in data being received, but it will not lose any data, because the new Broker node will pick up from where the previous one left off.
Broker reward
Brokers receive a reward for their participation based on the network fee rate, which is the system-wide parameter subject to change by on-chain governance. The reward depends on the number of messages the Broker has successfully delivered.
The reward is paid by the Subscriber. However, the Broker has to submit an attested cryptographic Proof of Delivery (PoD) in order to claim the reward. PoD is constructed by the Broker and has to be attested by multiple Observers until it can finally be submitted to the App Chain.
Broker shares a fraction of the network fee with Observers that are attesting to the PoD. The amount of this reward is proportional to the work done and is a fraction of the network fee paid by the Subscriber. Since Brokers are performing a lion’s share of the work by relaying the data, the vast majority of network fee is claimed by Brokers.
For more details on decentralized accounting, read here.
Broker exit
A Broker entity is able to exit the Data Layer in a sustainable way.
First, Broker nodes should signal the closure of the service to the Clients they are currently connected to. The signal should contain some future block height. This will give Clients time to gracefully disconnect from these Broker nodes and find other peers. During this period Broker nodes should also refuse all new connection attempts from Clients. The length of this grace period is set through on-chain governance.
Second, the Broker entity has to disconnect all its nodes. Since all Broker nodes are connected into a supercluster network, any node with spare capacity run by any other Broker entity is able to take on the workload that was refused by the existing nodes. This mass disconnect is required for the nodes to no longer participate in data delivery and to not generate the delivery information that will have to be included in PoDs.
Third, all the outstanding Proofs of Delivery have to be submitted on-chain by the exiting Broker entity. This is required, so that all Publishers whose data was served by these Brokers receive their rewards.
Fourth, after all the rewards are calculated and assigned, the Broker can initiate the exit by unlocking its credit. There’s a quarantine bonding period, during which the credit remains locked. This period is needed for Observers and Subscribers to present possible challenges that could revert the rewards and even slash the Broker’s credit.
As a last step, the Broker entity is now able to retrieve its credit and claim all the outstanding rewards. Failure to act according to this exit protocol will result in Broker's credit being slashed.
Trust assumptions
Brokers are trustless, this is due to several reasons.
Due to the highest crediting requirements, the slashing hits Brokers the hardest. It is in their best interest just to keep transferring as much data as possible.
Because of the existence of Observers, Brokers are discouraged from manipulations with accounting. A single proof that shows there was malicious activity on the Broker's behalf is enough to punish this Broker. This proof can be submitted by anyone, e.g. an honest Observer or a Subscriber, who was attacked.
There can be no competition between Brokers trying to sway the Clients their way because this part is regulated by the underlying NATS protocol.
Future work
All future work is the research and development that is planned, however, this cannot be seen as a commitment to deliver certain features.
Improved Broker node selection
Broker nodes situated close to a lot of clients will be enjoying a lot of connections. However, this might effectively degrade the performance of the service for some of those clients, since Broker hardware resources are limited. A mechanism that would take Broker node capacity utilization and other parameters into account is a desirable improvement.
Freeloading mitigation via continuous crediting
Due to the inherent token unlock algorithm, which results in Synternet token inflation, the credit of all service providers are losing their value at some rate. Therefore, requiring all actors to gradually increase the credit to compensate for this inflation could be a way to request for a continuous contribution from Brokers. A regular Broker entity would easily cover this requirement from the network fees they collect. However, a free-loader would need to buy a token from the market in order to cover the credit increase thus effectively paying for the data it is trying to free-load.
Freeloading mitigation via inactivity penalization
When a Broker is not submitting any PoDs to the App Chain regarding his work, a penalty can be imposed on such a Broker. However, an inactivity threshold, below which the credit is slashed, must be carefully selected, and can only be done in the future version of tokenomics, when common behaviors of service providers are observed for some time.