EOSIO 2.0
This release add support for ESIO 2.0 features, mainly WebAuthN keys support (no signing though) and WTMSIG_BLOCK_SIGNATURES
protocol feature that brings incompatibilities in the model layer when activated.
The v0.9.0 release add supports for that. We had to break compatibility of the type and field names in some base model present in the library. This was the occasion to make other "small" removal of some types that are not required anymore with the some small API changes of the EOSIO binary format decoder. Expect more structural changes to come in this area.
We renamed all fields that require logic changes from your code so you know quickly due to compilation errors that you need to handle some fields differently now.
Some fields were renamed and deprecated also, see Deprecation Notices section for further details.
WebAuthN Keys
The ecc
package has been upgraded to support WebAuthN key in EOSIO model. This supports add the following things:
- A new
CurveID
of typeWA
- Support for
PUB_WA_
keys from EOSIO - Support for
SIG_WA_
keys from EOSIO - Reconstruction of
PUB_WA_
format toecdsa.PublicKey
(recovery ofY
curve point from compressedPUB_WA_
public key form). - Verification of payload signature signed with with WA key (this is untested yet, but code is present).
WTMSIG_BLOCK_SIGNATURES Models
We now support all the models updates required for WTMSIG_BLOCK_SIGNATURES
protocol.
Breaking Changes
WTMSIG_BLOCK_SIGNATURES changes
The WTMSIG_BLOCK_SIGNATURES
enable block to be signed by more than a single key. When this protocol feature is activated, the block can be signed by multiple key, using a key with some weights and a threshold to reach, must like standard EOS permission.
This means that once activated, models for block signing and schedule are now different to support the new feature.
Here the list of changes that occurred, usually, more explanation can be found in the eos-go#p2ptypes.go file directly.
BlockSigningKey
in BlockState
has been renamed to BlockSigningKeyV1
and now a *ecc.PublicKey
This field can now be nil
, which is the case after WTMSIG_BLOCK_SIGNATURES
activation.
blockState.BlockSigningKey
now
if blockState.BlockSigningKeyV1 != nil {
// Deal with EOSIO 1.x model
...
}
ValidBlockSigningAuthorityV2
has been added to BlockState
This replaces old BlockSigningKey
and is of type BlockSigningAuthority
.
ActiveSchedule
in BlockState
is now of type *ProducerScheduleOrAuthoritySchedule
This new type contains both a V1
field (of type ProducerSchedule
) and a V2
field (of type ProducerAuthoritySchedule
). Old code that rely on ActiveSchedule
now must deal with either ActiveSchedule.V1
(old format) or ActiveSchedule.V2
(new format)
Important There is an ambiguity when deciding about the type the field active_schedule
can take since structure can be identical: {version:0, producers:[]}
and {version:0,producers:[]}
. This means both V1
and V2
field can be present at the same time. This is not a problem when serializing back to JSON since they represent the same JSON, but something you must be aware when doing your conditions around this new type as V1 != nil && V2 != nil == true
in some circumstances. The value could be discriminated by checking if ActivatedProtocolFeatures
contains the correct feature, it's something we suggest implementer to do in their own code for now, but it's in discussion for a direct usage in eos-go library.
blockState.ActiveSchedule
now
if blockState.ActiveSchedule.V1 != nil {
// Old format model or indistinguishable from `ProducerAuthoritySchedule`
}
if blockState.ActivateSchedule.V2 != nil {
// New format model or indistinguishable from `ProducerAuthoritySchedule`
}
PendingSchedule.Schedule
is now of type *ProducerScheduleOrAuthoritySchedule
Same logic as ActiveProducer
changes above, but apply to the PendingSchedule
type.
BlockHeader
NewProducers
has been renamed NewProducersV1
.
EOSIO 2.x does not have this field and has been replaced by a block header extension. Also, we changed how EOSIO binary optional value are handled throughout the library and removed the OptionalProducerSchedule
type, you now have a direct ProducerSchedule
field instead.
When the WTMSIG_BLOCK_SIGNATURES
will be activated, this field will never be populated anymore and must not be used anymore.
The new producers should now be extracted from the BlockHeader.HeaderExtensions
field. The library added supported for some know EOSIO BlockHeaderExtension
.
A block header extension contains a payload, when the producer_schedule_change_extension
block header extension is present, it means we are dealing with a new set of producers, as such, replacing the old BlockHeader.NewProducers
field.
if blockHeader.NewProducers != nil {
}
now
if blockHeader.NewProducersV1 != nil {
// Old format
}
OR
for _, e := range blockHeader.HeaderExtensions {
if e.Type == uint16(eos.EOS_ProducerScheduleChangeExtension) {
extension, err := e.AsBlockHeaderExtension("EOS")
if err != nil { ... }
// New format
scheduleChange := extension.(*eos.ProducerScheduleChangeExtension)
scheduleChange.Version
scheduleChange.Producers
}
}
Removal of GoAwayCrazy
enum for GoAwayReason
type
This field was not defined in EOSIO software, as such, it was removed. If you were relying on this field to be set, you will need to adapt your code to use another one.
Deprecation Notices
Those field were renamed to be in sync with other Golang fields. You should simply use the new field name. Those will be removed in a next major bump.
- Renamed
eos.TypeSize.UInt8
toeos.TypeSize.Uint8
- Renamed
eos.TypeSize.UInt16
toeos.TypeSize.Uint16
- Renamed
eos.TypeSize.UInt32
toeos.TypeSize.Uint32
- Renamed
eos.TypeSize.UInt64
toeos.TypeSize.Uint64
- Renamed
eos.TypeSize.UInt128
toeos.TypeSize.Uint128
- Renamed
eos.Decoder.ReadUInt8
toeos.Decoder.ReadUint8