Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploy Raiden smart contracts on Arbitrum #2909

Closed
taleldayekh opened this issue Aug 27, 2021 · 8 comments
Closed

Deploy Raiden smart contracts on Arbitrum #2909

taleldayekh opened this issue Aug 27, 2021 · 8 comments
Assignees

Comments

@taleldayekh
Copy link
Contributor

Description

Deploy Raiden smart contracts on Arbitrum testnet on Rinkeby.

Acceptance criteria

Tasks

  • [ ]
@taleldayekh taleldayekh added this to the Product Backlog milestone Aug 27, 2021
@taleldayekh taleldayekh added the 5 label Sep 3, 2021
@taleldayekh taleldayekh removed this from the Product Backlog milestone Sep 3, 2021
@palango
Copy link
Contributor

palango commented Sep 10, 2021

We probably have to change how to get block numbers.

The block.number opcode returns the L1 block number, which is not what we want on for raiden on arbitrum. See https://developer.offchainlabs.com/docs/time_in_arbitrum#ethereum-block-numbers-within-arbitrum

Seems like we have to change this to ArbSys(100).arbBlockNumber()

@palango
Copy link
Contributor

palango commented Sep 10, 2021

WIP PR: raiden-network/raiden-contracts#1530

@andrevmatos
Copy link
Contributor

@palango AFAIK, our usage of block.number is purely for timeout purposes, right? Would it be a problem if we kept the original source code for this? Using L1 blocks for our L2 deployments shouldn't matter as long as the timeouts are consistent.

@palango
Copy link
Contributor

palango commented Sep 10, 2021

That's true, but then we need to check how much the values deviate.

As a general rule, any timing assumptions a contract makes about block numbers and timestamps should be considered generally reliable in the longer term (i.e., on the order of at least several hours) but unreliable in the shorter term (minutes). (It so happens these are generally the same assumptions one should operate under when using block numbers directly on Ethereum!)

Seems that this might work.

@andrevmatos
Copy link
Contributor

The assumptions we already rely on the actual blockchain seems to be the same held true on the L2, so it shouldn't matter.

@palango palango self-assigned this Sep 16, 2021
@palango
Copy link
Contributor

palango commented Sep 22, 2021

Initial deployment is done. Now ewe have to see if we can get this into the LC easily.

The first token deployed is the normal one, the second one is used as the service token.

> npx hardhat --network arbitrum deploy
Nothing to compile
deploying "CustomToken" (tx: 0xcbacb92c0660f3998dcc25fbf3e78e6bb7373c866e1bc59013120a1fdff9f42d)...: deployed at 0x99C1aE38292791a52E26eE6AFdAeC69563F9b5C3 with 8730728 gas
deploying "CustomToken" (tx: 0x5bab7064108c2011fc9cddf038feb232d5f3e4b509a42381e0985474617f23a0)...: deployed at 0x4F92B7Cb0dBbc4d1c527461aFBb299B52B493E3b with 8741740 gas
reusing "SecretRegistry" at 0x2Cf93b81E624bAF880271Da9b796Ef35218eFEfD
reusing "TokenNetworkRegistry" at 0x1AFa9597409941B4d0A3b1Eb89742336958Da70a
deploying "ServiceRegistry" (tx: 0x172194bede2142b11cc291e99491ea72f9c25d1f9c40923b968af8965f8f5927)...: deployed at 0x76bFA2917e704E27142BfC2C56725FAa18543373 with 18017560 gas
deploying "UserDeposit" (tx: 0x8c5c3f8df6036d9375365cd55c9debd7e768272fbcd06ed50796350a5d2773aa)...: deployed at 0x0a3db745e3567907eAdB7CDd9EfFC9e23B8b6FeF with 10106347 gas
deploying "MonitoringService" (tx: 0x126d3afa6d4f6823dc55abb8421a124f862160102fc1165566e470fc6db6655e)...: deployed at 0x87B281aa8A638a0E3f3FB0f63b7D70348ACEde6d with 14246371 gas
deploying "OneToN" (tx: 0xb1f9162ac401383cd5d48079fb08482a6bcbb11c4f747f973069d6c7b740994f)...: deployed at 0xb58b16D651DCbAFE07516E959F7624fb9c528F5d with 8763574 gas
executing UserDeposit.init (tx: 0xb6ba643c92347531ebf4095993754c4c7bf5cdedd09c15a532d20ec55cae66cf) ...: performed with 1133626 gas

@palango palango closed this as completed Oct 6, 2021
@palango
Copy link
Contributor

palango commented Oct 6, 2021

settings for RSB services:

- PFS_TOKEN_NETWORK_REGISTRY_CONTRACT_ADDRESS=0x1AFa9597409941B4d0A3b1Eb89742336958Da70a
- PFS_USER_DEPOSIT_CONTRACT_ADDRESS=0x0a3db745e3567907eAdB7CDd9EfFC9e23B8b6FeF
- PFS_MONITOR_CONTRACT_ADDRESS=0x87B281aa8A638a0E3f3FB0f63b7D70348ACEde6d
- PFS_ONE_TO_N_CONTRACT_ADDRESS=0xb58b16D651DCbAFE07516E959F7624fb9c528F5d
- PFS_SERVICE_REGISTRY_CONTRACT_ADDRESS=0x76bFA2917e704E27142BfC2C56725FAa18543373

- MS_TOKEN_NETWORK_REGISTRY_CONTRACT_ADDRESS=0x1AFa9597409941B4d0A3b1Eb89742336958Da70a
- MS_USER_DEPOSIT_CONTRACT_ADDRESS=0x0a3db745e3567907eAdB7CDd9EfFC9e23B8b6FeF
- MS_MONITOR_CONTRACT_ADDRESS=0x87B281aa8A638a0E3f3FB0f63b7D70348ACEde6d
- MS_ONE_TO_N_CONTRACT_ADDRESS=0xb58b16D651DCbAFE07516E959F7624fb9c528F5d
- MS_SERVICE_REGISTRY_CONTRACT_ADDRESS=0x76bFA2917e704E27142BfC2C56725FAa18543373

- MSRC_TOKEN_NETWORK_REGISTRY_CONTRACT_ADDRESS=0x1AFa9597409941B4d0A3b1Eb89742336958Da70a
- MSRC_USER_DEPOSIT_CONTRACT_ADDRESS=0x0a3db745e3567907eAdB7CDd9EfFC9e23B8b6FeF
- MSRC_MONITOR_CONTRACT_ADDRESS=0x87B281aa8A638a0E3f3FB0f63b7D70348ACEde6d
- MSRC_ONE_TO_N_CONTRACT_ADDRESS=0xb58b16D651DCbAFE07516E959F7624fb9c528F5d
- MSRC_SERVICE_REGISTRY_CONTRACT_ADDRESS=0x76bFA2917e704E27142BfC2C56725FAa18543373

@andrevmatos
Copy link
Contributor

For completeness, the first TokenNetwork, for token 0x99C1aE38292791a52E26eE6AFdAeC69563F9b5C3, got registered on 0xE7d51343C332A58E81Ff101b8F1328A6d8290424 at block 5416883. With these information, one could create the respective deployment.json files for Arbitrum, to speed up startup/first sync, but as per #2913 (comment) , LC works fairly well with --user-deposit-contract-address parameter instead of the deployment.json file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants