Skip to content

EOSIO 2.0

Compare
Choose a tag to compare
@maoueh maoueh released this 22 Jan 16:50
· 138 commits to master since this release

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 type WA
  • Support for PUB_WA_ keys from EOSIO
  • Support for SIG_WA_ keys from EOSIO
  • Reconstruction of PUB_WA_ format to ecdsa.PublicKey (recovery of Y curve point from compressed PUB_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 to eos.TypeSize.Uint8
  • Renamed eos.TypeSize.UInt16 to eos.TypeSize.Uint16
  • Renamed eos.TypeSize.UInt32 to eos.TypeSize.Uint32
  • Renamed eos.TypeSize.UInt64 to eos.TypeSize.Uint64
  • Renamed eos.TypeSize.UInt128 to eos.TypeSize.Uint128
  • Renamed eos.Decoder.ReadUInt8 to eos.Decoder.ReadUint8