Release v1.7.14 #55
Release v1.7.14 #55
Conversation
|
|
||
| # Contents | ||
|
|
||
| This document explains the contents of the rc/v1.7.next1 release codenamed Interim. It is split in 2 sections: |
There was a problem hiding this comment.
Decided with @schimih that this one would be called Interim for now.
There was a problem hiding this comment.
| @@ -0,0 +1,124 @@ | |||
| [comment]: <> (tags/v1.7.16) | |||
There was a problem hiding this comment.
Maybe we should pick a proper semver tag, 1.8 (new features), even if we've mistakenly used 1.7next1 until now?
There was a problem hiding this comment.
Indeed 1.8 would be the correct choice, considering that features were also added. But we somehow reserved 1.8.0 for Andromeda release, thus only increased the last number.
| Relayed v3 feature brings a cheaper, improved version of relayed transactions, that can hold multiple inner transactions. | ||
| The inner transactions will be full transactions. | ||
|
|
||
| With this feature, a fix on the base cost of relayed transactions was implemented, to follow the minimum gas rule. |
There was a problem hiding this comment.
Additionally.
Also, maybe it should be specified that this additional fix affects all types of relayed transactions?
|
|
||
| With this feature, a fix on the base cost of relayed transactions was implemented, to follow the minimum gas rule. | ||
|
|
||
| ### Impact: |
There was a problem hiding this comment.
Maybe we should split the impact section into more sections - impact on validator, on developers, on integrators etc.?
There was a problem hiding this comment.
Additional note for integrators that read blockchain data - they need to handle relayed V3 transactions.
There was a problem hiding this comment.
added a note that v1 and v2 will be deprecated, should be pretty clear that this is a new type of tx that must be handled separately
|
|
||
| # Features | ||
|
|
||
| ## 1. Relayed v3 [#5741](https://github.com/multiversx/mx-chain-go/pull/5741) |
There was a problem hiding this comment.
Maybe link towards docs, as well?
There was a problem hiding this comment.
added. it was not pushed yet when I initially opened the PR.
|
|
||
| ## 3. Crypto API, new Opcodes and EGLD in MultiESDTTransfer [#6139](https://github.com/multiversx/mx-chain-go/pull/6139) | ||
|
|
||
| With this feature, new opcodes were enabled for developers, among with new crypto endpoints(`VerifySecp256r1`, `VerifyBLSSignatureShare`, `VerifyBLSMultiSig`). |
There was a problem hiding this comment.
We can specify that these endpoints are VM endpoints / VM EEI additions - since the word "endpoint" is a bit ambiguous.
| ## 3. Crypto API, new Opcodes and EGLD in MultiESDTTransfer [#6139](https://github.com/multiversx/mx-chain-go/pull/6139) | ||
|
|
||
| With this feature, new opcodes were enabled for developers, among with new crypto endpoints(`VerifySecp256r1`, `VerifyBLSSignatureShare`, `VerifyBLSMultiSig`). | ||
| Another improvement was EGLD as part of MultiESDTTransfer (EGLD-000000). |
There was a problem hiding this comment.
It's not obvious that since this upgrade, one can send native tokens along with custom ones by means of a MultiESDTTransfer.
There was a problem hiding this comment.
updated + added note
| With this feature, new opcodes were enabled for developers, among with new crypto endpoints(`VerifySecp256r1`, `VerifyBLSSignatureShare`, `VerifyBLSMultiSig`). | ||
| Another improvement was EGLD as part of MultiESDTTransfer (EGLD-000000). | ||
|
|
||
| ### Impact: |
There was a problem hiding this comment.
Additional note for integrators that read blockchain data - they need to handle EGLD transfers within MultiESDTTransfer.
| * No activation epoch | ||
| * No configuration files changes | ||
| * No binary flags changes | ||
| * No API endpoints changes |
There was a problem hiding this comment.
Any changes within the database structure that is worth mentioning?
Alternatively, replace section with a simple statement e.g. no impact on validators / developers etc.?
| * There are new enable epochs definitions for this feature, called `EGLDInMultiTransferEnableEpoch` and `CryptoOpcodesV2EnableEpoch` | ||
| * There are changes to the configuration options in the gas schedule files, new values were added for `VerifySecp256r1`, `VerifyBLSSignatureShare`,`VerifyBLSMultiSig` | ||
| * No binary flags changes | ||
| * No API endpoints changes |
There was a problem hiding this comment.
In this context, API is ambiguous: VM API vs. HTTP API. Perhaps say Node HTTP API (here and above)?
| @@ -65,14 +70,18 @@ The improvements implemented on ESDTs enable the dynamic NFT functionality. | |||
|
|
|||
| ## 3. Crypto API, new Opcodes and EGLD in MultiESDTTransfer [#6139](https://github.com/multiversx/mx-chain-go/pull/6139) | |||
|
|
|||
| With this feature, new opcodes were enabled for developers, among with new crypto endpoints(`VerifySecp256r1`, `VerifyBLSSignatureShare`, `VerifyBLSMultiSig`). | |||
| Another improvement was EGLD as part of MultiESDTTransfer (EGLD-000000). | |||
| With this feature, new opcodes were enabled for developers, among with new crypto VM endpoints(`VerifySecp256r1`, `VerifyBLSSignatureShare`, `VerifyBLSMultiSig`). | |||
| Another improvement was EGLD as part of MultiESDTTransfer (EGLD-000000). | ||
| With this feature, new opcodes were enabled for developers, among with new crypto VM endpoints(`VerifySecp256r1`, `VerifyBLSSignatureShare`, `VerifyBLSMultiSig`). | ||
|
|
||
| Additionally, EGLD(native tokens) can be now sent within MultiESDTTransfer (token identifier: EGLD-000000) along with custom tokens. |
There was a problem hiding this comment.
Formatting / missing space before parenthesis.
No description provided.