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
Create bridge contracts for Membership and ContentWorkingGroup module accoring to the initial design (#1520 (comment))
Those contract can be managed only by a specific address hardcoded in the runtime. For the purpose of initial tests we should be able to provide the "runtime address" during contract deployment.
Initialization
In order to initialize bridge contracts on the actual Joystream chain we woiuld need to:
Deploy the contracts
Export current members / CWG data
Initialize the data in the bridge contracts (using standard initalization process with batchInsert)
Make runtime aware of bride contract addresses (ie. we would need a SetBridgeContractAddresses proposal)
The problem in this scenario is that between steps 2 and 4, the memberships and curator working group state may (and most likely will) undergo some changes that the bridge contract will then not be aware of (since the runtime only starts to interact with it at after step 4).
This means we probably need to change the order of steps to 1, 4, 2, 3 order and make sure the contract is able to handle initialization and new changes coming from the runtime at the same time (ie. ignore member address provided in batchInsert if we already have one assigned)
This will make implementing a bridge contract a little more complex, but it should be plausible and it's probably worth the effort.
The text was updated successfully, but these errors were encountered:
Create bridge contracts for
Membership
andContentWorkingGroup
module accoring to the initial design (#1520 (comment))Those contract can be managed only by a specific address hardcoded in the runtime. For the purpose of initial tests we should be able to provide the "runtime address" during contract deployment.
Initialization
In order to initialize bridge contracts on the actual Joystream chain we woiuld need to:
batchInsert
)SetBridgeContractAddresses
proposal)The problem in this scenario is that between steps 2 and 4, the memberships and curator working group state may (and most likely will) undergo some changes that the bridge contract will then not be aware of (since the runtime only starts to interact with it at after step 4).
This means we probably need to change the order of steps to 1, 4, 2, 3 order and make sure the contract is able to handle initialization and new changes coming from the runtime at the same time (ie. ignore member address provided in
batchInsert
if we already have one assigned)This will make implementing a bridge contract a little more complex, but it should be plausible and it's probably worth the effort.
The text was updated successfully, but these errors were encountered: