Closed akolotov closed 6 years ago
@phahulin please move the card to in progress https://waffle.io/poanetwork/parity-bridge
@igorbarinov I get Only collaborators can update cards.
, looks like missing some permissions
@phahulin please try again
@akolotov I have a few questions
could you describe how authorities
should be used? At the present moment examples are not too descriptive because they use the same account simultaneously for home
, foreign
and 3xauthorities
. I suppose this is not a general case and accounts can be different. In general situation, where should authorities' keys be placed?
bridge's config toml contains parameters like required_signatures
, required_confirmations
, accounts
, if we run multiple instances of the same bridge, they should be initially synchronized across instances. But what would happen if they get out of sync later? e.g. on one instance required_signatures==2
but on another instance required_signatures==1
@phahulin
Currently we will assume that authority on particular bridge matches with the account which is used by the client Parity connected with the Foreign chain. Later, when we introduce RPC (#4) connectivity between the bridge and chains, we will disconnect Parity accounts and bridge authorities: Parity clients could be run without necessity to unlock accounts, the bridge authority will be a separate account which signs transactions and send them through RPC to chains.
Let's consider the config file. I will add comments to every line/section,.
estimated_gas_cost_of_withdraw = 0 <--- Should be the same on every bridge
[home] <--- Should be configured for every bridge separately account = "0x842eb2142c5aa1260954f07aae39ddee1640c3a7" ipc = "/home/koal/parity/PoA_home/jsonrpc.ipc" required_confirmations = 0 poll_interval = 2 request_timeout = 360
[home.contract] <--- Needed only on the deployment stage bin = "contracts/HomeBridge.bin"
[foreign]<--- Should be configured for every bridge separately account = "0xf3ee321df87781864f46f6464e764c2827fca73b" ipc = "/home/koal/parity/PoA_foreign/jsonrpc.ipc" required_confirmations = 0 poll_interval = 2 request_timeout = 360
[foreign.contract] <--- Needed only on the deployment stage bin = "contracts/ForeignBridge.bin"
[authorities] <--- Needed only on the deployment stage accounts = [ "0xf3ee321df87781864f46f6464e764c2827fca73b" ] required_signatures = 1
[transactions] home_deploy = { gas = 3000000, gas_price = 18000000000 } <--- Needed only on the deployment stage foreign_deploy = { gas = 3000000, gas_price = 18000000000 } <--- Needed only on the deployment stage deposit_relay = { gas = 1200000, gas_price = 18000000000 } <--- Should be the same on every bridge withdraw_confirm = { gas = 3000000, gas_price = 18000000000 } <--- Should be the same on every bridge withdraw_relay = { gas = 3000000, gas_price = 18000000000 } <--- Should be the same on every bridge
Those parameters which are the same for all bridges is very useful to store in the contract and extract every time when the bridge is started. It will help them synchronize from one place and we will make sure that are the same on every setup.
Actually we need to differentiate several different scenarios of deployments: deployment for developers needs and production deployment. DEV is actually two scenarios:
PROD is as described above
Could you preapare a note to describe possible ways to implement this as a playbook?
I propose the following scenario
Example: just for illustration let's imagine that there are only 4 options, in reality there will be more:
home_chain_json
: url - which chain spec json to use on home sideforeign_chain_json
: url - which chain spec json to use on foreign sidedeploy_contract
: bool - should playbook automatically deploy contractdb_toml
: string - path to local file db.toml to copy to the bridge serverNow we can have dev.yml
playbook that run all services, and have the following preset options (they will be stored in group_vars/dev.yml
file)
home_chain_json: "https://.../poanetwork/dev-bridge-chains/.../home.json"
foreign_chain_json: "https://.../poanetwork/dev-bridge-chains/.../foreign.json"
deploy_contract: yes
db_toml: ""
Users create hosts.yml
file:
---
dev:
hosts:
192.0.2.1::
ansible_user: ubuntu
run this playbook via ansible-playbook -i hosts.yml dev.yml
and deploy a ready-to-go configuration. They don't need to provide any additional options themselves (only server ip and ssh username). However, should they need to change some options, e.g. they want to use kovan as foreign-side, they can still do so by setting foreign_chain_json
in hosts.yml:
---
dev:
hosts:
192.0.2.1::
ansible_user: ubuntu
foreign_chain_json: "https://github.../paritytech/.../kovan.json"
options set in hosts.yml
overwrite those in group_vars/*
In the same way we can create prod.yml
playbook that don't have certain steps (e.g. contract deployment), configuration file group_vars/prod.yml
will be shorter
home_chain_json: "https://github.../poanetwork/.../core.json"
foreign_chain_json: "https://github.../ethereum/.../foundation.json"
and users will have to provide db_toml
option in hosts.yml
(since they are attaching to an existing bridge)
---
prod:
hosts:
192.0.2.1::
ansible_user: ubuntu
db_toml: "/home/joe/db.toml"
then they can run playbook via ansible-playbook -i hosts.yml prod.yml
Advantages of this setup imo are that
Concerns that I have at the moment:
Thanks Pavel (@phahulin) for good explanation.
Regarding parity configuraion - yes, the playbook should have an option to depoy parity config as well since it is related to spec of the corresponding chain.
Yes, deployment process depends on other issues. Could you point out most critical ones?
It's a bit hard to tell, because I have to guess implementation details and some of them are interconnected. From my best understanding
these are the issues that will require changes:
changes that should have a minor impact (config files mostly)
Bridge deployment is under separate repo: https://github.com/poanetwork/deployment-bridge
It is necessary to develop a procedure and corresponding automation to easily deploy bridge on several nodes.
Key points
home.account
andforeign.account
)home.ipc
,home.required_confirmations
,home.poll_interval
,home.request_timeout
,foreign.ipc
,foreign.required_confirmations
,foreign.poll_interval
andforeign.request_timeout
)bridge
process must be run as a service on target system.