Support staking on Harmony from ONE Wallet about one-wallet

[lijiang2087]

💪1️⃣💎

[polymorpher]

A third alternative is to alter 1 and validate signature differently, if the sender of the transaction is a contract. Since StakingTransaction relies on (r, s, v) signature values to calculate the sender's address, we should be extend StakingTransaction to accept a new type of StakingMsg and to include the contract's address, as well as the proof needed for validation. The validation of proof can be a call to a function on the contract (isValidSignature per EIP-1271), or hard-coded in Go similar to the flow in https://github.com/polymorpher/one-wallet/blob/master/code/contracts/ONEWallet.sol#L171.

At runtime, the client submits the staking request directly via hmy_sendrawstakingtransaction RPC call using the altered StakingTransaction structure proposed above.

This alternative requires much less modification compared to (2). It does not venture into customizing EVM and only customizes components that are already customized (RPC servers).

[rlan35]

A third alternative is to alter 1 and validate signature differently, if the sender of the transaction is a contract. Since StakingTransaction relies on (r, s, v) signature values to calculate the sender's address, we should be extend StakingTransaction to accept a new type of StakingMsg and to include the contract's address, as well as the proof needed for validation. The validation of proof can be a call to a function on the contract (isValidSignature per EIP-1271), or hard-coded in Go similar to the flow in https://github.com/polymorpher/one-wallet/blob/master/code/contracts/ONEWallet.sol#L171.

At runtime, the client submits the staking request directly via hmy_sendrawstakingtransaction RPC call using the altered StakingTransaction structure proposed above.

This alternative requires much less modification compared to (2). It does not venture into customizing EVM and only customizes components that are already customized (RPC servers).

The 3rd option is a viable option but it seems to me very hacky. It's altering staking txn structure and also staking txn validation logic, which is as heavy-weight as option 2 I think (the difference is it's not touching evm). Actually I think the option 2 is more elegant and generic and will help all other smart contract staking operations. I would prefer to go with option 2 even though it may take more time to implement.

Btw, we are making good progress on account abstraction: harmony-one/bounties#35. Though I don't think it will save us from having to change the staking logic on our side.

[hashmesan]

Btw, we are making good progress on account abstraction: harmony-one/bounties#35. Though I don't think it will save us from having to change the staking logic on our side.

@rlan35 When do you think it will be ready on testnet or mainnet?

[polymorpher]

Gnosis Safe is sort of handling contract signatures via options 3, by accepting the case that v=0 and using a variable length signature. See https://github.com/gnosis/safe-contracts/blob/34c87b783dfd04ff09ef7c358c3182c3c151e086/contracts/GnosisSafe.sol#L257

[polymorpher]

As of today, delegate and undelegate are added as smart contract functions (pre-compiled) on Harmony. Staking support on 1wallet is set to be added in mid March. harmony-one/harmony#3906

[polymorpher]

Fixed by #268