After completing the development process, we are happy to announce that a new product is joining the Lisk ecosystem - Lisk Service. Lisk Service is an essential part of the Lisk product line-up, as it offers the possibility to access and browse blockchain data, by providing accessible and powerful new API calls. Therefore, we published a blog post to introduce Lisk Service and it’s functionalities. As an addition to our blog post, on Monday, September 28th, Michal Tuleja (Lead Backend Developer) hosted a live AMA (Ask Me Anything) on Lisk.chat about Lisk Service.
In this blog post we recap the full live AMA session and feature the questions asked by community members, as well as the answers of Michał.
Monica Tartau opens the AMA:
Hello everyone! On September 17th, we published a blog post that introduces Lisk Service, a completely new product joining our ecosystem. Lisk Service acts as a service layer between blockchain data and user interfaces by providing accessible and powerful API calls. Michał Tuleja (@michal.lightcurve), Lead Backend Developer, is now here to answer any of your questions related to Lisk Service.
Michał: Hi everyone, My name's Michał, Lisk Service lead developer, looking forward to answering your questions!
Corbifex | Moosty: It looks like account api endpoints don't have an asset field anymore, will account.asset be implemented in Lisk-service in the future?
Michał: As of today, depending on the version of the Lisk SDK, there is a different level of compatibility. First, we are trying to achieve full compatibility with the SDKv2 and v3, then future versions. We will add the required field if there is anything missing.
JesusTheHun: Hi @michal.lightcurve! Why keep using a sql db instead of a nosql one? It makes a lot more sense in order to store json documents.
Michał: You're right, if we consider JSON document as our priority. We were considering some NoSQL databases as well at the beginning, the decision about using Postgres was made because we've already got several experienced Postgres developers in-house. Data aggregation features were also very important at this point. MongoDB was considered at some point, but if we want to keep the product open-source, the licence cannot restrict us.
JesusTheHun: There are plenty of other nosql options. What is the problem with the mongodb license? Also nearly all nosql products offer full featured aggregations. Today postgres is really an issue when trying to exploit asset data.
Michał: At some point, MongoDB migrated to SSPL licence and it wasn't clear if really can use it in that kind of project. That would require some legal considerations, but it isn't the only reason we decided to use Postgres instead. Remember that the number of blocks is increasing quickly and if we want to achieve great stability with large datasets, we need to use a solid, battle-tested DB.
JesusTheHun: I'm confused ... sql db are known to poorly scale horizontally, that kinda defeat your argument. That's one of the core reason people use nosql db, they scale horizontally very very well. So in a lisk mainchain centered system (which may or may not happen), a sql will fail with a probability of 1.0. But whatever, I heard your answer, "legacy".
Michał: I can agree with you to some extent, remember that this kind of technical decisions are not permanent - if we find a use case for a different DB we might also use it in the next versions.
JesusTheHun: Do you plan to add more features to lisk service? If so, can you share a list?
Michał: Yes, we are planning to add several features to Lisk Service. Just to name a few: Dynamic fee estimator, Multi-signature transaction support, and other changes that are coming with the SDK: voting, new transaction types, etc.
Corbifex | Moosty: Why are you focussing on v2 and v3? These versions are working already without the lisk-service?
Michał: In the long perspective, we are focusing on full compatibility with all versions of the SDK. Lisk Service is going to be an exclusive data provider for the UI products (Lisk Desktop and Lisk Mobile), that's why we cannot rely on the SDK/Core REST API only. As of today some features require Lisk Service and the data cannot be retrieved using raw SDK API. Next versions of Lisk Service are going to be developed parallel to the main product - the SDK.
JesusTheHun: Dynamic fee estimator will the lisk network be able to provide an exact amount? Multi-signature transaction support what kind of support are we talking about? Having a community voted list would be great.
Michał: So, the network activity will be monitored by Lisk Service and the fees are going to be calculated in real time and sent to the client on request. The suggested fees depend mostly on the network traffic, so the estimates should inform user how much should they pay for a certain processing speed. The implementation details are described in the LIP-16. The SDKv4 introduces a significant change to multisig transactions. The biggest difference from the user's perspective is they cannot broadcast the transaction unless all required signatures are collected. This is where Lisk Service takes responsibility - transactions without required signatures are stored in the database and other parties can add their signatures. Once all of them are collected, the transaction is broadcasted to the Lisk network.
JesusTheHun: You mean the transaction to declare an account multisig, not to sign a "business" transaction?
Michał: I mean the balance transfer from an multisig account. Without Lisk Service, it would require sending a partially signed transaction from one user to another, using some 3rd party tool ie. an email. Lisk Service can collect the signatures from all users and that transaction can be broadcasted through the Lisk network.
ducktank: Will Lisk-Service always be free to use? Or are there some ideas for lightcurve to earn with it?
Michał: Lisk Service is meant to be open-source and free to use. Moreover, all community contributions will be appreciated. I mean specifically the bug reports, patches, proposed features, etc. Lisk Service is an open-source product for a purpose, and the community involvement is very important to us! By the way, the project itself contains a template that shows how to start development with a custom microservice.
Corbifex | Moosty: What is the estimated time of arrival for the lisk services integration with sdkv5? Most of us are waiting atm for a fully working sdk 5.0 to create new proof of concepts, as the differences between v4 and v5 will be huge.
Michał: I cannot really speak for the SDK team, but as soon as the SDKv5 API is considered stable we can start working on it. As of today, I can tell that the SDKv5 brings many changes that we need to take into account. I think that the transition from the SDKv4 to v5 might require a little more resources than any previous one, but the Lisk Service team is also bigger now. That makes the future releases coming frequently, in timely manner.
Corbifex | Moosty: Why can't we consider the sdk v5.0 API stable yet? I don't find any open issues regarding that matter. Are you expecting more issues popping up?
Michał: To be precise, I wouldn't expect the v5 API to change much. The important factor to us is the Lisk SDK release schedule and the fact that Lisk Service is a new product with a lot of development ahead. We need to ensure the v4 compatibility first before we start implementing the next API client.
Corbifex | Moosty: But I thought SDKv4 would never end up on the mainnet we go straight to SDKv5 from the version we run now on mainnet, correct me if I'm wrong.
Michał: You are right, however we have to care about other networks and APIs as well. The Mainnet is not our only target, although a very important one.
Michał: Thank you for the questions. It was a pleasure to chat with you, hope this conversation was informative and please stay tuned for the future updates.
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: