search

hyperlane-xyz / hyperlane-monorepo

The home for Hyperlane core contracts, sdk packages, and other infrastructure
https://hyperlane.xyz
Other
313 stars 343 forks source link

Upgradable router and security of private keys #1287

Closed alerdenisov closed 7 months ago

alerdenisov commented 1 year ago

Hello, guys! Your product looks promising, nice done!

I just research your source code and understood all of them is upgradable. How it will work after mainnet launch, could you please share ideas about security of private keys?

P.S. Also should it check a caller to ensure payment for a gas?

yorhodes commented 1 year ago

We are currently operating with upgradable contracts such that we can respond effectively to catastrophic failures. Eventually, after we have turned on permissionless validating with staking, we will migrate away from upgradability, proxying, and any permissioned roles/keys. This is our progressive decentralization plan while remaining agile.

Ensuring gas payment is an off-chain social contract between the user and their relayer. Please refer to the relevant docs on interchain gas.

tkporter commented 1 year ago

Also worth mentioning that contracts are owned by a multisig of people close to the protocol. We can make this more transparent in the docs

alerdenisov commented 1 year ago

I love to see and understand that Hyperlane will do without an authoritative administrator!

I must be honest with you. I am Hacker of Tookey.io, we're building non-custody offchain access management protocol based on threshold signature scheme. Looks like our product doesn't fit to your decentralised way to operate, but I will appreciate if you can share your experience of using GnosisSafe to invalidate our product idea.

1) Is GnosisSafe making impossible to setup automation and operate in convenient way? 2) Did you experience lack of operability? When something need to be commited, but the multisignature has not yet been built.

Currently, we pivot technology as shareable private key solution. It allows to setup a wallet secured by three parts and at least two of them required to sign a transaction. If one part is stored on our server (and not enough to sign transaction) and second is shared with server (even CI/CD), it makes possible to automate operations with setup Web2 authorization to connect our part to signature building process.

We have an MVP solution where the owner approves a transaction in a telegram bot, but it can scale even to KYC or mobile call. By hardhat plugin integration of tookey as easy as hardhat-kms-signer and it compatible with hardhat scripts.

Do you think it's cool enough to integrate if you have a centralized protocol?

nambrot commented 7 months ago

Closing this for now, we are basically working on #3196 to address this problem, @alerdenisov please feel free to reopen with an update/questions