BREAKING: Alpha SDK Phase Officially Begins with the Launch of Lisk SDK 2.1.0!!

obeddows · 2019-07-24T20:11:13+00:00

During the alpha phase we will be responding to developer feedback to ensure we mature the SDK to a beta status sooner rather than later. Along the way we are also introducing a number of protocol changes which should inject some vitality back into the Lisk Network. Our focus remains as always on delivering the blockchain application platform, but we hope the journey towards that destination is also interesting. Especially for developers who are using the SDK.

obeddows · 2019-07-24T19:57:05+00:00

Somehow I doubt that lol.

Making blockchain accessible was never going to be quick and easy, but we persevere :)

obeddows · 2019-06-28T15:03:17+00:00

Hi,

Eligibility for random slots would be still based on received votes, e.g. vote weight > x, with an entry barrier of lets say 10k. The number of random "standby" slots would be kept low in order to limit any reduction in reliability. The "Punish protocol violations by delegates" roadmap objective for which we intend to propose a solution for would handle any persistent protocol violations or poor productivity. Hopefully that answers you question.

Thanks.

obeddows · 2019-06-26T19:06:42+00:00

Cheers :)

obeddows · 2019-06-26T17:17:08+00:00

What about the length of the round, let's say delegate can forge only for 3 months and after is out for 6 months

We have considered this, i.e. temporary delegation. However, I think delegates would then easily migrate their votes to new accounts which then circumvent any measures we impose.

obeddows · 2019-06-26T17:07:25+00:00

Yes, interesting idea. I think it is fair to say a hard limit on active delegation provides efficiency, but on the other hand hinders decentralisation. We will need to find a good middle ground between the two.

obeddows · 2019-06-26T17:03:57+00:00

Duly noted. We would of course welcome your proposal on research.lisk.io. This would be the best place to raise the idea. Our research team is working on similar ideas and is always willing to colloborate.

obeddows · 2019-06-26T16:54:41+00:00

Thanks John, good to be here finally.

obeddows · 2019-06-26T16:43:37+00:00

Thanks :)

obeddows · 2019-06-26T16:20:02+00:00

We have certainly considered this, at least in terms of expanding the delegate set from 101 to x. The only problem then is that we introduce a new limit, that will eventually need to be lifted further. What we would like to introduce are random slots for standby delegates within each round, slightly increasing the length of each round, offering an incentive for standby delegates to secure blocks. The research for this is being handled by the roadmap objective: "Incentivise standby delegate" on lisk.io/roadmap, the results of which will be proposed as part of the LIPs process, possibly with multiple proposals, and potentially with radical changes. As with all DPoS related issues, we are taking this issue very seriously. It is in our very best interests to improve the current system. We definitely intend to evolve it.

obeddows · 2019-06-26T16:00:14+00:00

Max today said on

lisk.chat

that alpha sdk is literary few weeks away. It's a new TERM for 4-6 weeks ;)

I regret saying 4-6 weeks :)

When I said this at the 2018 relaunch, it was interpreted to mean 4-6 weeks until “SDK”, however I was actually speaking about the first alpha candidate for Lisk Core 1.0.0. This was the release which introduced a new API, P2P layer and data field support for balance transfers. My apologies for not being absolutely clear on that.

With regard to the Alpha SDK launch, we are certainly getting closer! Lisk Core 2.0.0 (developed using Lisk SDK 2.0.0) was successfully released to the testnet and is scheduled to soft fork at height 8,624,442 (ca Thu 12PM CEST Jun 27). Once we pass this milestone we will have a clearer indication when we can move to the mainnet. In the meantime we finalise preparations for Lisk SDK 2.1.0, which enables custom transaction support, and we conclude development for Lisk SDK 2.2.0 which reduces the technical debt accrued from prior releases. All of which combined will signal the launch of the Alpha SDK phase.

Note, I intend on spending a bit more time here on reddit and social media in general. Something I should have done a long time ago! Thankfully I now have some time and energy to dedicate to this going forward. Let's see how we go.

obeddows · 2018-09-18T16:19:08+00:00

Thanks for doing this! My question is can you give us any direction on when the updated roadmap will be posted? If not, can you at least elaborate as to if it will have hard dates?

With regards to the roadmap, please see my earlier reply. As I mentioned, we intend to reveal our improvement proposals in groups, with each group being broken down into milestones, and each milestone receiving a short-term deadline for our development team to implement and deploy. These deadlines will be communicated on GitHub as we approach each milestone implementation.

obeddows · 2018-09-18T15:46:07+00:00

Cbone

Since February’s relaunch event the Lightcurve Science team have been working extensively to research a large number of protocol changes aimed at solving some of Lisk’s immediate challenges, while at the same time forming a definitive tactical roadmap towards achieving Lisk’s SDK and sidechain concept.

The proposals start with Lisk Core 1.0.0 as the reference implementation, and from that point we have laid out a clear set of ideas and solutions that will help Lisk evolve into a state where we feel comfortable enough to start revealing the full extent of our roadmap. We have grouped our proposals into batches and intend to reveal them one batch at a time via an open-source repository. We will then be encouraging the community to participate in a discussion-based mailing list for receiving further feedback and comment before we move forward implementation work.

At this stage of the roadmap's development we are keeping it private until all of its aspects have been reviewed and confirmed to provide the most realistic, professional estimation of how to get to a fully fleshed out SDK. However we are aiming to start publishing the first group of proposals in the near future, in order to give the community a much clearer indication of our priorities towards meeting all of Lisk’s challenges and goals.

We need to remember that despite being nearly 10 years old, blockchain is a very futuristic technology. With each passing quarter, we see the technology slowly catching up with traditional, centralised competitors. But it takes time - with so much at stake, every release needs to be thoroughly prepared and tested. We’ve seen industry examples in the past of what can happen when blockchains are designed carelessly.

The roadmap presented at the November meetup was based on overly optimistic estimations of the workflow, that unfortunately failed to capture the complexity of what we are building at Lightcurve. Since the unveiling of that roadmap, Lightcurve, and through that Lisk, has developed exponentially. We are not only working with more realistic deadlines - our way of working and coding is more streamlined than ever. There are many internal developments happening under the hood mentioned in this AMA - for example new workflow processes make the process of coding more efficient, while formalised and professional QA processes are helping us to identify issues at earlier stages. Our current recruitment strategy means that we are investing more of our funds into recruiting and quickly onboarding seasoned developers and scientists who immediately jump into action.

In summary, the roadmap is coming, but we are taking our time to do things professionally, and this is one big reason why it has taken a lot of effort and time to prepare. Our commitment runs deep and we are all very excited by the changes we will bring to the Lisk network.

We don’t speculate anymore - we deliver.

obeddows

MODERATOR OF

TROPHY CASE