Draft: Support EdDSA
Support EdDSA is rather complicated , quite some data structures in common folder need to be updated, as you might aware that change in the data structure is hard to version it , thus we might find out a hard fork might be required.
Here is a dump of all the things that I can think of at the moment, that need to be changed to support EdDSA.
In short: You will need to go through the code , make sure all the places use ObservedPubKey
, VaultPubKey
, Address From PubKey
has correct EdDSA pubkey , and the logic has chosen correct one.
changes in common folder
- Vault need to add a field to store EdDSA pubkey,
type_vault.proto
message Vault {
int64 block_height = 1;
string pub_key = 2 [(gogoproto.casttype) = "gitlab.com/thorchain/thornode/common.PubKey"];
repeated common.Coin coins = 3 [(gogoproto.castrepeated) = "gitlab.com/thorchain/thornode/common.Coins", (gogoproto.nullable) = false];
VaultType type = 4;
VaultStatus status = 5;
int64 status_since = 6;
repeated string membership = 7;
repeated string chains = 8;
int64 inbound_tx_count = 9;
int64 outbound_tx_count = 10;
repeated int64 pending_tx_block_heights = 11;
repeated types.ChainContract routers = 22 [(gogoproto.nullable) = false];
repeated string frozen = 23;
// TODO: add a field to store EDDSA pubkey
}
- Update
pubkey.go
, when get address from a pubkey - Update
type_tx_out.proto
, add a field for EdDSA PubKey of the outbound vault - update
type_observed_tx.proto
, currently it has a field callobserved_pub_key
, which is ECDSA, need to add an additional field for EdDSA pubkey.
changes to query
- Changes to
vaults/pubkeys
endpoint , return EdDSA PubKey as well - Changes to
vault/{pubkey}
endpoint , need to return vault based on the EdDSA PubKey as well
change to thornode message, handlers, managers
-
MsgObservedTxIn
, make sure all the places useObservedPubKey
has been updated to use the correct PubKey -
MsgObservedTxOut
, make sure all the places useObservedPubKey
has been updated to use correct PubKey , it has logics trying to figure out address based on chain and pubkey, for example https://gitlab.com/thorchain/thornode/-/blob/develop/x/thorchain/types/msg_observed_txout.go#L33 -
MsgTssPool
currently it has a field callpoolpubkey
which represent the TSS generated ECDSA PubKey, it need to add a new field for EdDSA Pubkey ,handler_tss
, need to be updated to set the EdDSA Pubkey on vault -
MsgTssKeysignFail
need to add a new field for EdDSA PubKey , and updatehandler_tss_keysign
to retrieve vault based on relevant pubkey accordingly [If bifrost can always make sure it set thePubKey
field inMsgTssKeysignFail
message to ECDSA pubkey , then this might not need to change] - Check all the places that use
ObservedPubKey
field onObservedTx
data struct, make sure the logic is correct. ( if we can make sure thatobservedPubKey
is always ECDSA pubkey , and it has been set to the correct key , even it is observed from a EdDSA blockchain , then we might not need to change it , but still need to make sure it is correct)handler_common_outbound
handler_consolidate
handler_errata_tx
handler_migrate
handler_noop
handler_observed_txin
handler_observed_txout
handler_ragnarok
manager_orderbook_current
manager_slasher_current
manager_swap_queue_current
manager_txout_current
- check all the places that use
VaultPutKey
onTxOutItem
has been updated correctly to use correct pubkey
Bifrost changes
- Bifrost observer need to updated to accept transaction sending to the EdDSA key related address
- It would be better for bifrost to keep a map between ECDSA pubkey and it’s relevant EdDSA key , so when a data type need pubkey , we can set both ECDSA PubKey and EdDSA key correctly
- new chainclient
TSS
- TSS need to be updated to support EdDSA
- TSS need to be updated to do two keygen back to back , one to generate ECDSA key , and a second keygen to generate EdDSA key , and only consider keygen success when both of these two Keys have been generated successfully.