The marked tokens have a byte flag associated with them which makes them parseable by rovers. The marked token transaction is stored in the Block Collider blockchain’s database as a part of the header of a block. But that would only occur after a successful transaction on the member chain, so really its when that occurs. It will be as fast as the multichain including a member chain block.
The congestion would occur on the member chain first, like cryptokitties. If transactions arent being pulled into a block due to congestion, the multichain and rovers arent picking up the state change. The multichain will mine as fast as blocks are made available to rovers to mine into the multichain.
Same answer as above.
I imagine it would, if there is not space left in the block, you cant fit more information. Im not entirely sure what would take precedence in that case.
So basically marked tokens are something to use in meta-contracts written for Block Collider. Ie state change on Chain A triggers something on Block Collider.
Pat described it in telegram previously. A standard set up without the use of marked tokens would look like the following:
So for instance lets say some event occurs on chain A which you have a meta-contract written for on the collider. The event could be any state change on chain A like “send chain A coin” or “redeem chain A coin” etc. In order for this event to execute you would need to pay the chain A fees to cause the state change on chain A. IN addition, you would have some fee for the resulting trigger on Block Collider’s own blockchain.
With the use of marked tokens:
HOWEVER if you used marked tokens with the event the fee on Block Collider is exponentially lower or free because the marked token transaction is stored in the Block Collider blockchain’s database as a part of the header of a block. Where as other transactions are not natively stored what is necessary for an SPV lite client.
What im reading from Pats breakdown is that as the transaction is seen as “native” to the multichain, is that the subsequent trigger on the collider is cheaper or free. It is a more efficient/cheaper way of confirming that a state change has happened and triggering the event.
Who benefits? Those who look to reduce their overall fees and overhead from having to have high frequency of state changes. This is why Pat points to DEXs as a prime example. Another one would be where there is a need to load balance across different chains, which would require constant monitoring and perhaps triggers to ensure the load balance is being effectively handled with as little over head as possible.