Andreas opens the AMA: Hey @everyone! @jan_lisk and me are ready for your questions regarding the high-level overview of the interoperability solution.

jan_lisk: Hello also from my side. Looking forward to your questions!

Corbifex | Moosty: Hi, Cross chain update transactions, will have a fee I presume? Who is paying the fees for these CCUs? As I understand you don't always have to do a CCU yourself.

Andreas: The user sending the CCU transaction needs to pay the fee. In return (as an incentive), the user sending the CCU receives the fees of the cross-chain messages contained in the CCU. No, the senders of cross-chain messages do not need to send the CCU.

Corbifex | Moosty: Nice, I was thinking about the incentive to do so. Will the messages fees always be higher than the cost of a CCU?

Andreas: No, there is no guarantee for it. It depends on how many messages are contained in the CCU and how large the remaining part of the CCU is. For example, if there are many validator changes on the sending chain, the CCU becomes a bit larger.

Jeevanio: If i want to send tokens from sidechain x to sidechain y, it goes through mainchain, i need to do a CCU on sidechain x and again a CCU on mainchain?

jan_lisk: You indeed need two CCUs. The first CCU would be submitted to the Lisk Mainchain and contain the cross-chain messages from sidechain x, the second CCU would be submitted to sidechain y and contain the cross-chain messages targeting sidechain y. Figure 3 in the blog post also gives a nice illustration of the scenario.

Andreas: Note that the sender only needs to send the cross-chain token transfer on the sending chains. The CCUs could be sent by other users.

Jeevanio: Delegates from sidechain x receive the CCU fee from CCU to mainchain, or mainchain delegates?

jan_lisk:The CCU is a transaction like any other transaction with respect to fees. If you submit it to the mainchain, the mainchain delegates receive the fees of the transaction (minus the part that is burned).

Captain_Slow: How does the implementation of interoperability compare to other items that have been on the roadmap (e.g. network longevity, network consensus)?

jan_lisk:We are not developers so we cannot give the expert opinion here. But note that many changes in the network longevity and network consensus phase were fundamental changes of the base protocol (e.g., new address system, ID system, ...). The changes introduced by the interoperability research mostly do not fundamentally change the base protocol, but build on the existing architecture of writing custom modules with custom transactions.

Captain_Slow: Has the industry response been what you were expecting from it? Anyone reached out to praise the work that you and the team did or has all noise been driven by marketing?

Andreas: We only published the high-level overview of our solution, not the detailed one. I guess experts in this area would only comment on it once the full solution is published. Therefore, there was not so much response from the industry.

Corbifex | Moosty: Will interoperability completely be implemented as a module (or multiple)?

jan_lisk: Note that the implementation of interoperability has not started yet so the development team still has a plan how to best implement it. But due to the complexity and amount of required functionality it should be split into more than one module.

Jeevanio: I pay with LSK fees in all sidechains and mainnet delegates get all these fees?

Andreas: No. The LSK token will be the default token for fees on sidechains, but sidechain developers can choose another token for fees on their sidechains. Transaction fees on sidechains go to the delegates/validators on the sidechain (unless sidechain developers really want to create a custom solution here).

Jeevanio: What could be a good reason to create our own token if we can use LSK everywhere ?

jan_lisk: The reasons for creating your own token would totally depend on your use case. Many use cases may not require this and then sidechain developers do not have to deal with complications of having their own token (especially legally). However, if you want to run a DPoS sidechain then it could make sense to have your own token for it. Also a token could be created for sidechain governance or for incentivization purposes.

Andreas: Note that you cannot mint LSK tokens on sidechains. This can only be done on the mainchain. If you want to mint tokens on sidechains, e.g., for rewards, it needs to be another token.

Frida: Will multiple options (tokens) be possible to pay the fees with, or has the developer/ sidechain operator to decide for one token users will have to pay transaction fees in?

Andreas: So far, the plan is to allow only one token for fees on one chain.

Jeevanio: In that case if there is a poker sidechain with custom tokens, I can use LSK on the chain to gamble but still need sidechain tokens to pay fees?

Andreas: It depends on which token the sidechain developer is choosing. If the LSK is chosen as the fee token, then users must pay fees in LSK. If a custom token is chosen for fees, then users must pay fees with this custom token.

Jeevanio: But if a custom token is chosen, can I still use LSK on the chain, right?

Andreas: If the gambling transactions accept LSK for gambling, then you can use your LSK tokens for gambling. This is again a decision from the sidechain developers. But the fees must be paid with the custom token.

JesusTheHun: Is it possible to NOT have a custom token and therefore use LSK?

Andreas: Yes, it is possible to not use custom tokens on a sidechain and to do everything with LSK.

jong: How can cross-chain messages inside a CCU be used to modify the underlying blockchain state (e.g. update account balances to reflect the data in the message)? Will new custom modules need to be implemented to interpret the messages?

jan_lisk: The CCU follows the same paradigm as other custom transactions, it only has a more complicated asset. As for any other transaction you can modify the state (e.g., account balances) depending on the content of the transaction asset. For the exact architecture of the cross-chain messaging processing I would refer to Lisk.js where we present all technical details. Some basic cross-chain messages (e.g., for balance transfers) would be specified as part of new modules. The general approach is similar to transactions: there is a base message and then developers can develop custom messages with a custom asset.

Corbifex | Moosty: If you have Alice, Bob and Charlie on sidechain x. Alice transfers LSK to with a custom transaction Bob and Bob transfers part of those LSK to Charlie with a custom transaction. How does Charlie prove that he can send those LSK to the mainchain?

Andreas: The CCU from x to the mainchain that contains the cross-chain tokens transfer message (CCTTM) from Charly contains a proof that the CCTTM was emitted, included and finalized in the sidechain. The full details regarding this proof will be revealed at Lisk.js.

JesusTheHun: How will the mainchain know what IP to broadcast the CCU to?

jan_lisk: Regarding your questions about the IP: The mainchain itself does not have to know it, only the relayer that submits the CCU. What the relayer would do is: 1) Call API from known mainchain node to obtain data for the CCU 2) Submit CCU transaction via API to known sidechain node. So the relayer needs to know IP addresses/domain names of both a sidechain and a mainchain node.

JesusTheHun: This is a big requirement, the only safe way to do that is for the relayer to run a node of the mainchain and the destination chain.

Andreas: Not really. Querying the sending chain via the API is kind of trustless because the information you receive (certificates) is signed by a large portion of the validators, and for all other parts there are proofs for the correctness. And for the receiving chain node, it is not required to run it on your own.

Corbifex | Moosty: Can sidechains/mainchain trust the CCU and its content without any checks from the receiving chain on the sending chain?

Andreas: Yes. The same answer as before applies here.

JesusTheHun: It's more about availability than trust, it's hard to rely on a node you do not control. Even if you pick one that responds, when the mainchain sends a request to that destination node, it may be down or struggling at this very moment. Is there a built-in retry mechanism?

Andreas: That's an implementation question that I cannot answer yet. It's something that has to be considered during the implementation.

JesusTheHun: Block size is limited to 15kb, what is the max size of a CCU?

Andreas: The size limit for a CCU is only implicit: it must fit into a block. Therefore, a CCU cannot be larger than 15kB on the mainchain.

JesusTheHun: How the mainchain transaction pool will manage this, since a 15kb transaction will need to be alone in the block to be treated. Does it treat the transaction in received order? If so, maybe a block will contain only 1 transaction because the next one is 15kb, losing some space in the block.

jan_lisk: The problem of choosing which transactions to put in a block is basically the knapsack problem. I believe that our transaction pool uses a greedy heuristic to fill blocks with transactions, i.e., always choose the transaction with the highest fee per byte that still fits. So a 15 kb transaction would only be included if it has the highest fee per byte of all pending transactions. Therefore it may be a better strategy for relayers to submit smaller transactions.

JesusTheHun: It is averaged out to the transaction pool, right? I mean if there are 35 transactions for a total of 5kb and X LSK fees in the transaction pool. Those transactions are in competition with a transaction of 15kb. So if the total amount of fees Y > X then the 15kb will go first right?

jan_lisk: I assume Y is the fee of the 15 kB transaction in your example. I agree that the optimal solution for the case Y>X would be to include the transaction with 15 kB. But the greedy algorithm is a heuristic that does not always find the optimal solution (finding it is NP hard as it reduces to the knapsack problem). The greedy algorithm would first include one of the smaller transactions in a block if it has higher fee per byte.

JesusTheHun: And this scenario: if there are 60 transactions for a total of 35kb in the tx pool. The pool has an average fee per byte of X0. The first 15kb of tx who have the highest fees per byte have an average fees per byte of X1, the 15kb tx have a fees per byte of X2. If X1 > X2 > X0 who goes first ?. Still the greedy approach?

jan_lisk: Yep, as far as I know, the transaction pool always uses the greedy approach. So basically: 1) Sort transaction by fee per byte (actually the non-burned fee per byte). 2) Insert transactions to block starting with the highest fee per byte until no transaction in the whole pool fits. Note that a relayer has the choice to submit only a subset of the cross-chain messages. So if a 15 kB CCU does not get through, it could send two 7.5 kB CCUs instead (it is not completely linear, but close to).

JesusTheHun: Did you study the impact of the block finality requirement on business use cases ? I'm thinking about delays before being able to trigger a CCU.

Andreas: No, we did not study this. But improving time to finality could be a potential future research topic for us.

jong: Will LiskHQ mainchain implement some kind of mechanism to allow a sidechain community to lock some LSK into a special address (or a special account on the mainchain belonging to the sidechain) to provide LSK liquidity for the sidechain to use? Or this is outside the scope of the research?

jan_lisk: All LSK transferred to a sidechain A would anyway be put in an escrow account for sidechain A so that sidechain A cannot arbitrarily inflate the supply of LSK. All these LSK in the escrow then have a pegged counterpart in the sidechain (you do not literally transfer Lisk, but created a pegged token on the sidechain). The sidechain is then completely free to have any logic how to use the LSK, e.g. for liquidity, and the sidechain logic determines under which conditions LSK are transferred back to the mainchain via cross-chain messages (i.e. out of the escrow).

jong: Ok, it sounds like the sidechain has to start with 0 tokens in circulation and the tokens can only be created on the sidechain when LSK is locked up on the mainchain?

JesusTheHun: It can start with any amount of custom token it wants, but it starts with 0 LSK token.

Andreas: Yes, that's correct.

jong: It seems that if you start with x amount of custom token but then the conversion ratio cannot be 1:1, each LSK should be worth multiple sidechain tokens. How will this ratio be determined? Can this be specified during sidechain registration?

Andreas: We do not provide exchange functionality. This must be implemented by the sidechain developers. A way to exchange different tokens could also be a DEX sidechain.

jong: If the sidechain starts with 2 times more custom tokens in circulation than it has LSK locked up on the mainchain (and a 1:1 conversion ratio is enforced), then it's possible that the sidechain could run out of LSK tokens on the mainchain if people try to convert more than half of the custom tokens into LSK on the mainchain.

Andreas: Well, technically that would mean that all LSK tokens are transferred to that sidechain. With every token you move to the sidechain, the price for LSK would increase. Hence the last token would be overly expensive. So, it is not really a realistic case.

jong: Ok thanks. Maybe I'm thinking about it incorrectly. I was thinking if the sidechain starts with 50 million custom tokens and then (hypothetically) the LSK community sent 50 million LSK to the sidechain then the total supply of custom tokens on the sidechain would show as 100 million custom tokens? But there would only be 50 million LSK on the mainchain for that sidechain to use.

jan_lisk: There is no fixed exchange rate between custom tokens and LSK. Every sidechain starts with 0 (pegged) LSK and 0 LSK in the escrow. If 5 LSK are transferred to the sidechain, 5 LSK go to the escrow on the mainchain and 5 (pegged) LSK are created on the sidechain. If the 2 LSK are transferred back, then 2 pegged LSK on the sidechain are destroyed and later removed from the escrow on the mainchain. For custom tokens the sidechain can define any initial supply and assign it arbitrarily to users how they want it. This is completely independent of how many LSK are in the sidechain as there are two independent tokens contained in the sidechain (pegged LSK and custom tokens) which do not have a fixed exchange rate.

Jeevanio: Current chains like Leasehold need to lock LSK tokens in an escrow account? worth the total market cap of the current chain?

Andreas: Well, the whole amount of LSK tokens that is supposed to be transferred to the sidechain needs to be escrowed.

Andreas: Ok everyone. Thank you very much for the interesting questions. It was a pleasure. Looking forward to providing you the missing detail at Lisk.js.

jan_lisk: Thanks for the many good questions! We all in the research team are looking forward to sharing and discussing all details of the interoperability solution with you at Lisk.js!

Thanks to everyone in the community for their participation in the live AMA on Lisk.chat. Further information about the research presented in the blog post is available on the Research forum. We invite all community members to read the LIPs and engage in discussion over there. More details about Lisk interoperability solution, the research objectives, and the LIPs addressing them will be revealed at the next Lisk.js event on May 21st-22nd, 2021.