The Broadcaster

Interacting with Coinweb consists of reading data and writing data. The reading part is covered by Coinweb nodes that expose access to state, typically through accessing claims, and RDoC verification of these claims.

The writing part can be done by writing directly to L1 blockchains, but is usually done by utilizing a broadcaster service.

The broadcaster allows transactions to be paid for in CWEB regardless of the underlying L1 gas token. It does this by simulating and pattern matching the transaction, ensuring that it will receive CWEB to cover its expenses.

A broadcaster needs to have access to L1 tokens for the various networks it supports embedding into, and also needs to keep track of gas fee prices.

What transactions will a broadcaster accept?

The Broadcaster does not necessarily support broadcasting any transaction that is possible to construct (it would have to solve the halting problem to know if it would get paid), but will recognize certain patterns that it deems safe.

Due to the transactional model in Coinweb, the broadcaster does not need to do a full analysis of a transaction to know if it gets paid, it only needs to know that any exception or error that an attacker tries to inject happens after the transaction that pays the broadcaster has been committed.

One simple way to do this is to push a transaction through a well defined Delay contract that simply delays execution of any transaction by one execution step, thereby disconnecting the transaction that pays the broadcaster from the rest of the transaction.

In the following example, only what is inside the enclosed area requires simulation as what is outside should not affect whether the broadcaster gets paid¹. The transaction that goes "boom!" takes down the delay transaction, but does not affect payment to the broadcaster.

info

The payment guarantee to the broadcaster depends on the transaction semantics in Coinweb and would not work in an isolated transactional system as the one in the Ethereum VM

Footnotes

1. Some additional requirements on the code still exists such as other transactions not being able to force transaction failures through double spend and in general clashing Take operations. ↩