You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use golang/json package's default formatting of bytes in our cluster definition and cluster lock json objects which is base64 standard.
This is causing problems for DV-launchpad as it uses the definition config hash for routing to its backend and base64 standard isn't URL safe.
Proposed solution
The following formats are available to choose from:
hex: We leave hex for "eth2" things like group pubkey and ENRs. We want to use a different format for charon/obol specific things so users are less easily confused. Like thining the DV pubkey is one of the pubshares since those would also look like addresses.
base64 URL: base64 URL addresses the problem of using base64 in URLs be replacing "/" with "_" and "+" with "-". This could work but the resulting encoding still contain "special characters" which can be hard to work and look at for humans.
base58: base58 is both URL safe and human friendly. It only contains alpha numeric characters exluding look-alikes like "I" and "l". Base58 is also a common format in other crypto currencies, but not ETH (yet).
Final proposal:
We therefore suggest refactoring all byte fields from base64 standard to )x prefixed hex since that is the Ethereum standard which simplifies the config and aligns it with our industry.
These fields include:
cluster-definition.config_hash
cluster-definition.definition_hash
cluster-definition.operators.config_signature
cluster-definition.operators.enr_signature
cluster-lock.lock_hash
cluster-lock.signature_aggregate
cluster-lock.distributed_validators.public_shares
Increase the version from 1.1.0 to 1.2.0.
Since this is only cosmetic (the data is unchanged), the new logic should be backwards compatible with v1.0.0 and v1.1.0 files. Note the new file format v1.2.0 will not be compatible with old logic.
This can be achieved by created 2 sets of "json formatters", e.g. lockJSON_v1_1 (for old) and lockJSON_v1_2 (for new). All child formatters (definition, operators, distributed validators) would require the same.
funcs func unmarshalLock_v1_1(*Lock, []byte) error should then implemented to contain the separate logic.
Add backwards compatibility unit and smoke tests
Out of Scope
No other config upgrades included.
The text was updated successfully, but these errors were encountered:
@OisinKyne I think we should actually upgrade cluster-definition.operators.config_signature and cluster-definition.operators.enr_signature to hex (not base58), as they are standard EIP712 signatures which are commonly hex with 0x prefix. Leave lock.signature_aggregate as base58 since that is a BLS sig.
Introduces **draft** cluster config version `1.2.0`. EIP712 signatures are refactored to industry standard hex. Other base64 fields are refactored to base58 to be URL safe and easy for humans to work with.
`v1.2.0` will contain more upgrades, so not "released" yet.
category: feature
ticket: #848
corverroos
changed the title
Refactor cluster definition and lock hashes to base58
Refactor cluster definition and lock fields to hex
Jul 26, 2022
Problem to be solved
We currently use
golang/json
package's default formatting ofbytes
in our cluster definition and cluster lock json objects which is base64 standard.This is causing problems for DV-launchpad as it uses the definition config hash for routing to its backend and base64 standard isn't URL safe.
Proposed solution
The following formats are available to choose from:
Final proposal:
cluster-definition.config_hash
cluster-definition.definition_hash
cluster-definition.operators.config_signature
cluster-definition.operators.enr_signature
cluster-lock.lock_hash
cluster-lock.signature_aggregate
cluster-lock.distributed_validators.public_shares
lockJSON_v1_1
(for old) andlockJSON_v1_2
(for new). All child formatters (definition, operators, distributed validators) would require the same.func unmarshalLock_v1_1(*Lock, []byte) error
should then implemented to contain the separate logic.Out of Scope
No other config upgrades included.
The text was updated successfully, but these errors were encountered: