Iker Alustiza opens the AMA:

Hey @everyone! I am already here for the AMA of the "Introduction to Blockchain Interoperability" that we published yesterday! Feel free to throw me any question or comment you have about it, I will try to answer them all in the next hour or so.

Splatters: How is going with the research, and at this point do you have any idea on when or almost a close period of time when the Interoperability can be delivered?

Iker: The research of the interoperability solution is in a very advanced status. As @Alessandro and @MaxKordek already said, the goal is to publish the whole solution for Lisk.js 2021, which will happen in spring. But before that, our developers have already started looking into it and planning its implementation, at least for those topics that are more like support for the interoperability protocol than the protocol itself.

Splatters: So this spring we're gonna see the solution written on paper? If so how long it will take to be written as a working code and delivered on the Lisk protocol? I don't want any exact date, but just want to understand if the major problem was finding the solution, and the small part is making it work as a code.

Iker: As Max said, there will be a total of 19 LIPs describing the interoperability solution, around 5 or 6 of those are what we called "supporting LIPs" which are needed to deliver the solution. A good example of this is the Sparse Merkle Tree specification that @Alessandro mentioned back in the day. @Splatters, I think @MaxKordek gave recently a nice explanation in that direction as in how the steps until final release look, in particular for 2021.

What I can say for sure is that as you said, the solution should be entirely specified on a paper (LIPs) by spring and then ready for you all to give feedback and review. Then the platform development team will go full effort to implement it and test it.

korben3: Hi @IkerLIsk Will there be a point that a large number of sidechains might slow down the transactions on the mainchain?

Iker: Well, depends on what you mean by "slow down". The main concept for our solution is that sidechains will compete for mainchain blockspace as any other transaction. So a high number of sidechains will not slow down the mainchain but increase the fee per byte needed to be included in a block, which is the expected behavior in the fee system we designed. But for more details about how this will work, you will need to wait for our next blog post which will cover our solution.

korben3: Thanks for the answer, I'll wait with further questions about this until after the next blog post. Another one: What kind of sidechains would you like to see being built?

Iker: **Personally, I don't have a preference for the kind of projects to be built in the ecosystem. I am very excited with the fact that any kind of project will be able to be built with the SDK and that we will have a solid and well-researched interoperability protocol for all these projects to communicate and thrive in a diverse ecosystem. I would love to see that happen, the more projects, the more sidechains, and greater added value.

bagdonex: The interoperability protocol will be structured as a network protocol? Ex. TCP

Iker:Some of the interoperability LIPs will have a flavor in that direction, as in a protocol for communication between two entities (message types, handshakes, errors...), but of course there is much more behind that. Again, you will know more about that in the next blog post.

Corbifex | Moosty: Did you already start writing blog part two?

Iker: That next blog post (2nd part of interop series) will be written by my colleague Andreas in the Research Team. I am not 100% sure if he already started it but it should be out around the middle of March. Bear in mind that our top priority for the team is to fully specify the solution and complete the LIPs so we are not going to spam you with too many blog posts, at least not before Lisk.js.

Andrzeyerb: Is there a chance to introduce the ZK rollup? In future?

Iker:Do you mean as part of the interoperability protocol that allows cross-chain interactions? Or implemented in a specific sidechain to allow certain features (privacy, scalability)? If it is the second question, then that will be totally up to the sidechain developer to implement. The developers can create any custom logic for their blockchain application and they will need to follow the interoperability standard protocol to be part of the Lisk Ecosystem.

Andrzeyerb: I mean about interoperability protocol.

Iker: In principle, we are not going for anything close to zk-rollups for the interoperability solution. In the blog post, I wrote that this is still a very new technology and in their current form they don’t allow having a general message solution. If you saw @Alessandro's presentation at our Lisk Center Berlin event in November, you may guess how the solution may work... and if you haven't, just wait for the next blog post where this will be discussed.

Jurre | Moosty: Since you have done extensive research into the interoperability protocol I am curious how you look at the examples you have seen so far. Can you say something about the different platforms/solutions you have researched? Which one you think is most mature or which approach you like the most?

Iker: Oh! that is an interesting question. Of course, I could write another blog post just to answer it, but let's try to be concise: For me the really interesting solutions out there are those that allow transferring any general message between the interconnected chains, those that I put under the "General Cross-Chain Messages" section of my blog post.

That is why we are specifying a solution in that direction for Lisk Inside that framework, it will depend on what is the specific goal or use case of your blockchain ecosystem...

But if you want my personal opinion, I think that Polkadot is proposing a very interesting solution, the problem is that it is very complex and they have already a hard limit in the number of parachains the ecosystem can deal with. I would not say it is the most mature though because their message passing protocol is still a work in progress so who knows if/when they will deliver it.

Cryptdong: Hi @IkerLIsk : You just mentioned the fees which would be increased with a high number of sidechains (which is to be expected if Lisk becomes adopted). Do you expect a similar fee behavior for Lisk as it is with BTC and ETH at peak times (incredibly high fees)? If not, how do you mitigate this behavior of "high transaction fees"?

Iker: That is a good question that may be better answered in the next months, but let me give you a first answer: The main point in a blockchain ecosystem with interconnected chains is that each of these chains will serve a use case and they will "only" send cross-chain messages when needed.

This means, the high transaction load happens in each of the sidechains and the mainchain will only be used when enough cross-chain messages are waiting for their delivery from one chain to the other. This puts the scalability limit many orders of magnitude higher than a system with a unique chain.

liskvote: Good evening! Are you thinking about interoperating with different blockchains like Polkadot and Cosmos?

Iker: At the moment, the interoperability solution aims to interconnect homogenous blockchains of the Lisk ecosystem. These are blockchains that follow a certain protocol and technology stack so that they can communicate between each other. Beyond that, two considerations: a) no one will stop a sidechain developer to create a bridge sidechain to interoperate with other external blockchains(as you can see with some projects inside Cosmos or Polkadot for BTC or Ethereum). b) It is not decided yet but likely one of the main topics of research for my team after the interop solution is 100% completed will be the interoperability with external blockchains.

korben3: Must be an awesome feeling to start seeing a lot of developers using the product, the SDK, you've helped to build. And in what creative ways they use it.

Iker: Totally! I can't wait for that to happen! Months ago I was already very excited when our developers implemented the LIPs I wrote, but this will be a whole new level of "accomplishment feeling" inside me.

przemer: What would be the biggest shortcoming of Lisk's interoperability comparing to for example Polkadot’s approach? And what would be better with Lisk?

Iker: Yep, this will be one of the most important questions to face, especially outside the community. Let's see if I can put it in short: Polkadot proposes a unique interoperability solution for their ecosystem with this so-called "pooled security" idea.

That may look very interesting (especially from a research point of view) but there are also risks and other drawbacks: First, as it is unique, they will need to be very careful not only with bugs but also with theoretical attacks and failures. Secondly, as I said before, its high complexity implies that a limited number of parachains (and therefore projects) can connect to the ecosystem.

It is starting to be clear in their community that to be part of the Polkadot ecosystem a high initial investment will be needed for the parachains developers. This one is a shortcoming that the Lisk interoperability solution will not have. The entry barrier for the ecosystem will be much lower, the initial investment, at least technically, to be part of the ecosystem is not going to be a problem. But again, you will know more about this in the next episodes.

toster: You said: no one will stop a sidechain developer to create a bridge sidechain to interoperate with other external blockchains. Do you think that standardized bridges to operate with popular blockchains might appear in Lisk SDK so that devs don’t have to produce their own bridges with little to no standard? This would be a killer. Just saying.

Iker: Very good point. Lisk is a decentralized project at the end of the day so it will be up to the network participants to decide what is "standard" and what is not. In that way, it may be that a well-researched and developed solution from the community will take the "standard" spot. I would love to see that! And I am not saying that because it will imply less work for me but because this will mean that there is a strong and decentralized community developing for the Lisk ecosystem.

ducktank: Do you consider the complexity of implementing interoperability in your research? Maybe a tough question, but if all LIPs are written, does it need years to implement? Will the implementation go on mainnet in more steps or all in one?

Iker: Regarding the last question, I don’t have many details at the moment, I think that the development team has to first have the whole reviewed solution in front of them to assess how to release it eventually.

Regarding the first one: I don’t want to diminish the devs team efforts, but in this case, I would say that the complexity of specifying the interoperability solution is higher and takes way longer than implementing it.

Bear in mind that this specifying task has involved: - a research phase trying to collect every single idea which is technically relevant - Fitting that collection of ideas to the vision of the project - define how it should work as a whole - define how every piece should fit in the whole framework - Specify on a paper how every detail of the solution should work so that the implementation task is easier for the dev team So I won't say it "takes years" to implement, also, all the tools to implement it are already available in our SDK.

Iker: ok guys! that is it for the AMA! I hope you took some interesting notes and ideas from it. And just to repeat myself, stay tuned for the second episode of this interoperability blog posts saga and, of course, the whole interoperability solution publication for Lisk.js! Have a great weekend.

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.

Lisk has embarked on an exciting mission to enable developers to create decentralized, efficient, and transparent blockchain applications. Stay up to date and join us on:

• Lisk.chat
• Lisk Research forum
• Lisk Dev forum
• Lisk SDK Page
• Twitter