Golem Alpha IV reveal

The Alpha IV of Golem is out and this means that we’re here to update you on changes, particularly for developers of apps that already run on Golem

Golem Alpha IV reveal

The Golem Alpha IV release is out and this means that we’re here to update you on changes, particularly for those developing apps that already run on the testnet (see Awesome Golem for a list) or that are looking to create apps on the upcoming official mainnet release. This release contains important changes to backwards compatibility that we will cover at the end.

Before we dive in it’s good to note that this release is in essence a release candidate for mainnet that will be Tested In Production (TIP). As such, there are some mainnet functionalities included and already Golem users are able to use real GLM for payment.

This release contains important changes to backwards compatibility that we will cover. Applications built on this release will be compatible with the upcoming official mainnet release so for any creators, developers and requestors you have the potential to get started early with updating your Apps or creating new ones targeting the official mainnet release!

Important changes for requestors

The Alpha IV release (Yagna v0.6.0) is not backwards compatible with the previous Alpha release (Yagna v0.5.0). This is on the Yagna network protocol level, which means that nodes running the previous Alpha will not be able to communicate with those running this latest release.

There are new versions of the Yagna Python API (YaPAPI v0.5.0) and Yagna JS API (YaJSAPI v0.3.0). Here it’s important to note that the APIs are not backward-compatible, so for developers of applications using Golem in previous releases, the apps themselves would have to be updated for them to run with the Alpha IV.

As for Golem VM Images, these remain compatible, so there is no need to make any changes to the images for them to run.

We are looking into potential incentivizations for developers updating their applications for the new APIs although it won’t be before the next release. In the meantime, we will continue to support requestors running Alpha III and community.3 subnet up to the next release.

Important Changes for Providers

While this isn’t the official mainnet release, due to it being a TIP release candidate for mainnet it does include some mainnet functionality. If you want to run your provider on testnet then you can include a flag --payment-network rinkeby when starting your provider. golemsp run with no flag will start the provider on mainnet. After starting as a provider on your preferred network, all settings on a provider can be kept at default for it to start and run successfully on a supported system. For more information on playing with your provider settings, see the Provider CLI.

To get started with the latest release!

As a requestor there are some changes to the initialization process that you can follow in the Requestor Flash tutorial. Here you can also find the Yagna (v0.6.0) binaries.

As a provider the startup flow is the same from a user experience perspective. Those who have run as a provider in the past (or as part of the provider bounties) might notice some quality of life improvements to the status table.

Remember that if you’ve run previous versions of Yagna in that past that you should purge stale working directories first. This release will use the subnet community.4 by default.

Yagna Changelogs

Event API
We have also seriously reworked our REST APIs by unifying Event-related calls across all of them (Market API, Activity API, and Payment API), which is called internally "Event API".

Longer tasks via Debit Notes "keep alive"
Providers and Requestors are able to negotiate and conclude long-lasting Agreements for long-running tasks/activities. This requires the Requestor to continuously accept Debit Notes issued by the Provider (aka "keep alive").

The full changelogs for Yagna can be found here and includes updates to; Payment Service, Payment's part of Event API refactor, Activity Service / ExeUnit, Activity part of Event API refactor, SGX, Market Service, Market's part of Event API refactor, Service Bus, GFTP, Metrics Service, Identity Service, Version Service, Provider, goth and among others improvements.

Before we finish up, here’s a fun fact; there were 124 Pull Requests merged in the Yagna repository between the previous release and the Alpha IV. That’s a lot of coding - we cannot be prouder of the Golem team!

Thank you for reading, if you have any questions or feedback about this release the please join the Golem Discord chat and let us know.

This release is a tribute to recently passed away "Papcio Chmiel" - the author of Tytus, Romek & A'Tomek.

Yapapi Changelogs

Major features

  • Event API (#196)
  • Payment Event API (#193)
  • Support for execution of multiple activities within bounds of a single agreement
  • Support for "Terminate agreement" REST call (#194)
  • Agreements pool (#188)
  • Score-based offer selection (#199)
  • Select payment platforms based on driver/network specification (#215)
  • Support for accepting debit notes as keep-alive messages between the provider and the requestor (#219)

Minor features, fixes and improvements

  • Support SRV addresses for Golem infrastructure components (#200)
  • Support newer REST API bindings (ya-aioclient=0.4.1) (#214)
  • Emit warning from summary logger if computation timeout is outside 5--30 min range (#175)
  • Bugfix for using max on empty list in AgreementsPool._get_agreement() (#201)
  • Use DemandOfferBase model class in Market API calls (#203)
  • Don't send terminate command to exe unit before destroying activity (#204)
  • Log scoring results to debug log (#216)
  • Add __init__.py to make examples dir a package and facilitate imports (#220)
  • Add py.typed to yapapi to make the package PEP 561 compliant (#221)
  • Add id and provider_name properties to WorkContext.remove log() method (#222)
  • Set encoding to "utf-8" for the debug log file in log.py (#226)
  • Handle KeyboardInterrupt in AsyncWorker's task (#228)
  • Include provider ids in keys in SummaryLogger maps (#224)
  • Update "no payment account" message to refer to the handbook (#231)
  • Update debit note timeout property name (#234)
  • Fix yapapi.log.log_event() (#232)
  • Log yapapi version and Executor() arguments to file (#235)
  • Don't print total time on executor shutdown; do print it in examples (#240)
  • Fix deadlock in AsyncWrapper's stop() coroutine (#243)

Yajsapi Changelogs

Major features

  • Support for yagna's Event API (#97)
  • Update payment and market api's (#94)
  • Score-based offer selection (#93) (#102)
  • Rename, refactor the codebase (#89)
  • Add typedoc, configure for html & markdown (#81) (#103)
  • Select payment platforms based on driver/network specification (#104)
  • Support debit notes as keep-alive messages (#111)

Minor features, fixes and improvements

  • Resolve the image repository using the SRV record (#105)
  • Move logsummary to utils (#55)
  • Move cancellationToken to Engine (#60)
  • More sgx runtime names + simplified code (#64)
  • Cancel worker, subscription when computation ends (#68)
  • Final fix for invoice event (#73)
  • Fix total cost printing (#74)
  • Sign new agreements only if there are unassigned tasks (#76)
  • Add logging to linear market strategy class (#109)
  • Use provider ids as keys (#112)
  • Fix file transport and total cost amount (#113)
  • Fix log filename issue on windows (#114)
  • Update debit note timeout property name (#115)
  • Update subnet, fix network flag in js example (#116)
  • Change dequeue logic with channels (#80)
  • Graceful quit (#118)
  • Fix batch timeout
  • Disable streaming / enable polling
  • Fix getInvoiceEvents parameters
  • Set default timeout to 1 day
  • Simplify destroying activity
  • Handle HTTP 408 when confirming agreements
  • Fix double spending information display
  • Fix consumer flow with asyncWith wrapper, fix logs
  • Clean dependencies with npm script
  • Update clean script with rimraf for cross-platform
  • Remove waiting for completed workers