State channels breaking changes

As a consequence of the introduction of generalized accounts there are some breaking changes to the state channels implementation that need to be merged (the changes are documented in this PR ).

This changes will require a new major release of the node and consequently will require a new major release of the SDKs to support the new node version.

On the positive side this will not impact consensus (no hard hard fork) and will not require change on the applications that uses the SDKs since the changes are under-the-hood, but anyway it will require to eventually update your node and the SDKs on your app with it. Also if you are relying on the API Gateway for your app this will affect you (btw, you should always use on your own infrastructure :wink:) for live projects).

And now the plan.

The plan is to merge this change for the next scheduled release that will happen in a bit more than 2 weeks time (around the 18th of July), followed by a release of the SDKs (Js/Py/Go) and with the API Gateway being upgraded one week after on the 25th of July. This release will be the v4.0.0 for the node.

Hopefully this will not be too disruptive for you, but if you have concerns please share them here so we can address them properly.

5 Likes

“The plan is to merge this change for the next scheduled release that will happen in a bit more than 2 weeks time (around the 18th of July), followed by a release of the SDKs (Js/Py/Go) and with the API Gateway being upgraded one week after on the 25th of July. This release will be the v4.0.0 for the node .”

Does this mean that dApps will have to update their contracts, nodes and js(sdk) contract calls?

Will we have some backup compatibility of the JS SDK and Sophia Contracts? (Last update in the beginning of June, have broke the SDK and Sophia contracts - any backup compatibility at all)

It is important question, because it costs a lot of time and resources for the dApp developers to build an AEpp and then to basically rebuild it every month - month and a half.

Thank you for the response in advance :wink:

1 Like

hello @tima_t, thank you for reaching out, I will try to clarify as much as possible.

If you are running your node, hosting your compiler and your dApp is working with the current SDK and you are not using state channels then you don’t have to do anything. The release for the node is only relative to low level state channels communication, it doesn’t affect consensus and it doesn’t affects contracts.

If you are using the hosted compiler though (but more in general for contracts), you may want to check this one.

If you are using the API Gateway then you will have to update the SDK (because the node will receive the update).

If you are depending on state channels in your dApp you will have to eventually update both the node and the SDK if you want your node to be able to communicate with other nodes that may upgrade to the latest release.

About the problems you have experienced at the beginning of June, are they related to the changes announced in this post? I ask because we want to avoid as much as possible any disruption but sometime it is inevitable and the only way we have to mitigate it is to announce it beforehand and we are looking for the best way to do so.

And last but not least, the next big update that you can plan for is around mid September, where the HF will take place and will require an update of the node, SDK and probably for contracts too.

1 Like

I think this is the best-practice every Blockchain application developer needs to follow.

1 Like

This is why everything is versioned. If you stick to one version and host it yourself you should not have any problems - i know this is asked a lot but its a decentralised ecosystem and developing Blockchain applications comes with either this, or trusting a third party to do the job for you (like Infura for example in Ethereum)

Thank you for the detailed reply!
I think it is more than enough for now.

1 Like