Python SCORE end of life timeline

With the introduction of Java smart contract support in ICON 2, python SCOREs should be fully deprecated in the future.

Although python SCOREs require a very strict audit process to be published in mainnet, some of them still have very poor performances. When they are executed, they can dramatically slow down the network and everyone is therefore impacted by this.

The ICON Foundation will provide financial or technical support for teams who want to migrate their legacy python applications to Java (see Python SCORE migration to Java).

Core developers and I believe we should aim to completely remove python SCORE support as soon as possible, to reduce the uncertainty related to those legacy contracts being executed on mainnet.

This is a big change, but we believe that if it’s well planned and executed, it will greatly benefit the network in the future.

Therefore, I would like to discuss a possible complete deprecation of all python SCORE within 9 months. Python SCORE support would be deactivated and it would not longer be possible to execute them after the deadline. All related python SCORE code would therefore be cleaned up from goloop as well, remove a big technical debt from the source code.

Please provide your feedback on this and let’s prepare an IIP once we think we are ready to do so.

Thank you.

4 Likes

Hi,

The main feedback regarding the original post was the following: Since we don't know when Java SCORE will be enabled on main net, it's hard to tell if 9 months is a good timeline.

The Java SCORE activation proposal will be submitted today (upon no technical issue detected with the network) and hopefully activated within ~24 hours. Therefore, it’s time to discuss this again.

P-Reps, community developer, could you please provide your feedback on the original post and/or the two following questions:

  • Should Python SCORE be deprecated in the future, meaning that you will not be able to execute them anymore? (all of them would be set to read only)
  • If yes, when would this be a good time? Originally proposed 9 months after Java SCORE activation. If you think that’s too short/too long please explain your reasoning.
  • Any other feedback is appreciated. Please also talk with your P-Reps about this, they will decide.

Thank you.

I think 9 months is a fair offer, could just push it to 12 months, 1 full year since we are launching rev 15 at the end of this year. This also needs to be addressed to the Foundation for the support they’ll be providing to converting the python contracts and a guarantee that they’ll be able to convert them within the time (or they’ll extend the time if they are running behind).

I think 9 months is a short time. There are around ~1000 python contracts currently. Some are not being used anymore. I would suggest for 15-18 months time.

Will Token contracts need to be converted from Python to Java ?

Yeah, seems so. Every contract which needs to have write transactions needs to be translated to Java.

Stick to 9 months, you get 15 months. Pick 15 months, we will be here for years lol

I was thinking of adding a new feature to destroy python scores so that the owners who don’t want to translate python scores and are of no use any further could be destroyed. Not sure if it has added advantage to leaving the scores just read only.

Deprecating Python SCORE means actually deprecating Python Execution Environment. In other words, It means dropping support for running the Python SCORE at all. This includes removing the iconee source code from goloop repository completely.

So I suggest full one year (12 months) deadline after the Java SCORE activation, this will be the end of this year. Very simple. DApp owners should migrate their DApp to Java by the end of this year (2022).

However, practically, DApp owners should migrate their DApp to Java as soon as possible manner. The more Python code you added, the more difficult it becomes to migrate to Java.

Also I want to emphasize that the current audit process for the existing Python SCORE is actually is not for big upgrade, rather it is for small maintenance update to earn time until the later Java migration. Do migration ASAP.

1 Like