As a major release, 2.0 includes many changes large and small, including a few breaking changes. The following changelog captures significant new and altered functionality and capabilities but is not exhaustive.
The most significant breaking change is that the block structure has been changed. All blocks produced as of 2.0 forward will use the new format. All blocks produced during 1.x remain and are still accessible. The block header includes a protocol version field, both in 1.x and in 2.x, which allows programmatic detection and handling of this change.
The next most significant breaking change is the json-rpc server has been moved from the node itself to a separate sidecar application, and a lower level binary port API has been added to the node instead. However, from a consumers perspective, interactions with a node instance that is also running the sidecar are seamless and retro-compatible as it sits at the same address and supports the original API.
Aside from breaking changes, there are some capabilities that continue to be supported but are deprecated / are subject to removal in the future. Most significantly, the 1.x deploy model is deprecated but continues to be supported throughout 2.0. A new transaction type that supports more functionality is the go-forward. Deploys continue to be able to do everything they previously could do, but new functionality (such as native auction interactions) is not compatible with the deploy model.
Related to the introduction of the new transaction model, internal logic that previously used the term 'deploy' in a general sense has been renamed to use the term 'transaction' in all places except where intentionally and explicitly referring to the actual 1.x deploy structure. For instance, the deploy_buffer component has been renamed transaction_buffer; it handles both legacy deploys and go-forward transactions. This has no direct impact on downstream logic, but is evident in logs and metrics and in settings. Any 3rd party log or metric readers explicitly watching for deploy related activity in any of those places will need to be updated.
Most of the architectural changes in 2.0 are to support to allow transactions to target multiple runtimes has been added to the node logic and transaction structure. Global state handling has been decoupled from the 1.x wasm vm machinery and is now accessible in other flows. This and other changes allows the node to support any number of target runtimes.
At launch, 2.0 contains three such runtimes, native and the 1.x wasm vm are enabled for mainnet. A new functional wasm vm also exists and can be turned on for a given network via chainspec, but is disabled for mainnet as it is in a beta state.
In 1.x deploys could bypass most but not all of the machinery of the wasm vm runtime to interact with the mint specifically for transferring token. In 2.0, the new native runtime allows transactions to directly target all user-facing native mint and auction methods with no involvement of a vm. This improves convenience and is also more efficient allowing more transaction volume.