Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 23 2019 14:12
    tomusdrw opened #232
  • Oct 23 2019 14:11

    tomusdrw on tumski

    (compare)

  • Oct 23 2019 10:30
    tomusdrw commented #231
  • Oct 23 2019 10:30
    tomusdrw closed #231
  • Oct 23 2019 10:30
    tomusdrw review_requested #231
  • Oct 23 2019 10:30
    tomusdrw opened #231
  • Oct 23 2019 10:19

    dependabot-preview[bot] on cargo

    (compare)

  • Oct 23 2019 10:19

    tomusdrw on master

    Bump env_logger from 0.6.2 to 0… (compare)

  • Oct 23 2019 10:19
    tomusdrw closed #230
  • Oct 22 2019 08:47
    dependabot-preview[bot] labeled #230
  • Oct 22 2019 08:47
    dependabot-preview[bot] opened #230
  • Oct 22 2019 08:47

    dependabot-preview[bot] on cargo

    Bump env_logger from 0.6.2 to 0… (compare)

  • Oct 22 2019 08:44

    tomusdrw on cargo

    (compare)

  • Oct 22 2019 08:44

    tomusdrw on master

    Bump rustc-hex from 1.0.0 to 2.… (compare)

  • Oct 22 2019 08:44
    tomusdrw closed #228
  • Oct 22 2019 08:06

    tomusdrw on cargo

    (compare)

  • Oct 22 2019 08:06
    dependabot-preview[bot] commented #222
  • Oct 22 2019 08:06
    tomusdrw closed #222
  • Oct 22 2019 08:03
    tomusdrw synchronize #228
  • Oct 22 2019 08:03

    tomusdrw on cargo

    Update. (compare)

joshua-mir
@joshua-mir
@ramxis, this hasn't been finalized yet, but communication between parachains will likely be much more streamlined - at the very least at the developer level it should be as simple as an ordinary call (except you won't get a value returned immediately as communication between parachains would be asynchronous)
If you are making a call into a parachain that has smart contracts, you'd probably need to specify its address, but it would still be a native call from within your chain/contract
Serialization and deserialiation are things we already provide in substrate
ramxis
@ramxis
@joshua-mir I figured it will be easier using parachains, but in most cases it might not be possible for people to redeploy their private blockchain based solutions as parachains. The best we could do is connect to relayChains using the bridge parachain. But it will be really useful if we could have a generic serialization and deserialization library atleast for EVM based blockchains.
joshua-mir
@joshua-mir
It's certainly on the roadmap, but I can't say when those tools will be available.
Rahul Bishnoi
@nanspro
Hey @joshua-mir thanks to your help i was able to run the bridge a few days back.
But i am not able to change state in BridgeRecipient(deployed on side chain), i am calling Main.relay(data, bridgerecipientaddress) and it returns with success. My recipient contract's accept message is supposed to change a value from true to false and since state change happens through a transaction i should be able to see a tx in my side POA chain but that is not happening. Looks like bridge is not talking to recipient at all. How can i debug or fix this ?
Rahul Bishnoi
@nanspro

BridgeRecipient

pragma solidity ^0.5.0;

contract Test {    
    bool public heads;

    constructor () public {
        heads = true;
    }
    function acceptMessage(bytes calldata data, address sender) external {
        require(sender != address(0));
        require(data.length !=0);
        heads = false;
    }

    function get() external view returns (bool) {
        return heads;
    }
}

I am using remix to call Main.relayMessage("0x54676545", 0x43AB9938388C6aD102d4868053D7762A635941c7)

Rahul Bishnoi
@nanspro
Also the bridge automatically stops after 7 minutes with this error Bridge: polling main to side sign failed, Request timed out
Guillermo Pérez Alba
@gperezalba_gitlab
Hi, I'm trying to build parity-bridge and I'm getting an "error: failed to run custom build command for openssl v0.9.24 Unable to detect OpenSSL version... I've tried everything to try to solve but error persist...
Guillermo Pérez Alba
@gperezalba_gitlab
@joshua-mir
ddorgan
@ddorgan
you have libssl-dev installed?
Guillermo Pérez Alba
@gperezalba_gitlab
Yes I have
And pkg-config too
ddorgan
@ddorgan
and you're running: cargo build -p parity-bridge -p parity-bridge-deploy --release ?
Guillermo Pérez Alba
@gperezalba_gitlab
I tried to modify my Cargo.lock according to those changes (which seem to resolve a similar error) https://github.com/paritytech/substrate/pull/913/files but when I run 'cargo build ...' again the Cargo.lock updates to te original version
@ddorgan Yes I run this command
Guillermo Pérez Alba
@gperezalba_gitlab
It seems the error doesn't appear in Ubuntu16.04... is the error related with Ubuntu 18.04 in some way?
ddorgan
@ddorgan
Yeh exactly had just tested that ... older ubuntu has openssl 0.9.7 ... ubuntu 18 = 1.1.1
Guillermo Pérez Alba
@gperezalba_gitlab
My ubuntu16 has openssl 1.0.2g I tried downgrading openssl to 1.0.1 in ubuntu18 but error persisted...
The only "solution" to fix it in ubuntu 18 is to downgrade openssl to 1.0.2g? or is there any other option?
Guillermo Pérez Alba
@gperezalba_gitlab
Is the frontEnd code of https://bridge-dashboard.parity.io/deposits available somewhere???
Guillermo Pérez Alba
@gperezalba_gitlab
Hi! Can I use a client with light sync as a part of a bridge?
joshua-mir
@joshua-mir
@gperezalba_gitlab I wouldn't recommend it, but I imagine it's possible.
Guillermo Pérez Alba
@gperezalba_gitlab
Yes, finally I used a full node...in my POA no I need a validator node? or it can be a non-validator?
joshua-mir
@joshua-mir
It can be a non-validator, but again, it's not recommended as validators have more guarantee that their transactions get included in a timely manner
@gperezalba_gitlab
Honest Blocks
@HonestBlocks
Hi guys. I just discovered Parity Bridge. Is it compatible with geth? I want to bridge a private PoA network and ropsten, both deployed with geth.
joshua-mir
@joshua-mir
@HonestBlocks in theory, you just need to point the bridge at an Ethereum endpoint so geth might work, but I haven't heard of anyone using it, and all of parity-bridge's integration tests run parity-ethereum 😅
Honest Blocks
@HonestBlocks
@joshua-mir thanks. I'll check if that works out
ramxis
@ramxis

@joshua-mir I tried to call a function on my side chain and my bridge crashed with the following message.

Bridge: polling side to main sign failed

Caused by:
  RelayStream: relaying logs failed

Caused by:
  WithdrawConfirm: message signing failed

Caused by:
  Request timed out

Now I get this message whenever i try to restart my bridge.
I deployed the bridge.sol contract manually on both my side chain and main chain using metamask.
The contract code for the caller contract is:

pragma solidity ^0.5.0;
import './bridge.sol';


contract TestMain  {
    string testData = "cp event fired";
    bytes  funccallsidedata = '022519df000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000082272616d65657a22000000000000000000000000000000000000000000000000l';
    string setData;
    event CP_EVENT(string);
    Main instance = Main(0x75Ca77F0F69dC7fdfA1c974E73dEBe821C55FB32);
    address TestSideAddress = 0x407d3449819A6e47ce43687d58B3C00dCed77bc8;

    function Existing(address _t) public {
        instance = Main(_t);
    }

    function triggerEventOnSide() public {
        instance.relayMessage(funccallsidedata, TestSideAddress);
        emit CP_EVENT(testData);
    }

    function funcCallOnSide() public {
        bytes memory funccallsidedata2 = '022519df000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000082272616d65657a22000000000000000000000000000000000000000000000000l';
        instance.relayMessage(funccallsidedata, TestSideAddress);
        emit CP_EVENT(testData);

    }
    function funcCallWithOutPutOnSide() public pure returns (uint){
        return 26;
    }

    function testLogik() public {

    }

and the side contract which i am sending the call to:

pragma solidity ^0.5.0;
import './bridge.sol';
contract TestSide is BridgeRecipient  {
    string testData = "cp event fired";
    string setData;
    event CP_EVENT(string);
    event extFuncCallStatus(bool);


    function triggerEvent() public {
       emit CP_EVENT(testData);
    }

    function funcCall(string memory data) public {
        setData = data;
        emit CP_EVENT(data);
    }

    function funcCallWithOutPut() public pure returns (uint){
        return 26;
    }

    function acceptMessage(bytes calldata data, address sender) external {
        // get and fire function call
        bool status;
        bytes memory data;
        (status , data) = address(this).call(data);
        emit extFuncCallStatus(status);
    }
}

I called the funcCallOnSide() which caused the crash.

ramxis
@ramxis
any idea how to get rid of this error ?
joshua-mir
@joshua-mir
@ramxis the request timing out might be due to accounts being locked on the relevant nodes
ramxis
@ramxis
@joshua-mir which accounts? I am trying to call funcCallOnSide from the Main contract it generates the transaction. This should call the acceptMessage() function on the side right ? how are any accounts besides the authority accounts relevant ?
joshua-mir
@joshua-mir
Exactly - the nodes running the bridge, and controlling the authority accounts, need to be able to make transactions. If they are not unlocked the transactions will remain in the Signer queue and the rpc query might time out.
ramxis
@ramxis

@joshua-mir the transaction gets mined on the main chain, I have the same authority on both chains as you suggested earlier and the both nodes have access to authority passwords using the .pwds file , I am not sure what I am missing.
here is my node setup

# This config should be placed in following path:
#   %AppData%\Parity\Ethereum\config.toml
[parity]
chain = "c:/parity/PoA1.json"
# determines the directory that a Parity instance uses for data and keys
base_path = "c:/tmp/PoA1"
[network]
port = 30301
[rpc]
port = 8541
cors = ["chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn"]
apis = ["web3", "eth", "net", "personal", "parity", "parity_set", "traces", "rpc", "parity_accounts"]
[websockets]
port = 8451
[account]
password = ["C:/parity/chain1pwds.pwds"]
[mining]
engine_signer = "0x00Aa39d30F0D20FF03a22cCfc30B7EfbFca597C2"
reseal_on_txs = "none"
min_gas_price = 0x0

here is Node2 Setup:

[parity]
chain = "c:/parity/PoA2.json"
# determines the directory that a Parity instance uses for data and keys
base_path = "c:/tmp/PoA2"
[network]
port = 30302
[rpc]
port = 8542
cors = ["chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn"]
apis = ["web3", "eth", "net", "personal", "parity", "parity_set", "traces", "rpc", "parity_accounts"]
[websockets]
port = 8452
[account]
password = ["C:/parity/chain2pwds.pwds"]
[mining]
engine_signer = "0x00Aa39d30F0D20FF03a22cCfc30B7EfbFca597C2"
reseal_on_txs = "none"
min_gas_price = 0x0
(please note, these nodes must not be publicly accessible 😅)
ramxis
@ramxis
@joshua-mir I am failing to understand what you are saying, If my authority accounts were locked wouldnt contract deployment failed, and also would it not also fail to mine transactions. It would be helpful if you could give me a single option that i can toggle in my .toml file or any command line that i can run to fix this ?
this is my parity bridge log :
 INFO 2019-07-30T15:22:48Z: bridge::log_stream: LogStream: fetched confirmed block number 10
 INFO 2019-07-30T15:22:48Z: bridge::log_stream: LogStream: fetching logs in blocks 2 to 10
 INFO 2019-07-30T15:22:48Z: bridge::log_stream: LogStream (topic: [0x3626c9e69e592ca494da4d6abe2abe54bd68d0c04e51d88d26c2c24d212203a1]): fetched 0 logs from block 2 to block 10
 INFO 2019-07-30T15:22:48Z: bridge::log_stream: LogStream (topic: [0x3626c9e69e592ca494da4d6abe2abe54bd68d0c04e51d88d26c2c24d212203a1]): fetched 1 logs from block 2 to block 35
 INFO 2019-07-30T15:22:48Z: bridge::accept_message_from_main: 0xe06c7c5f85b0811b0df0c5a06251b52b1c55e6209321c4fd970a36ed0bd31165 - step 1/4 - fetch message using message_id
 INFO 2019-07-30T15:22:48Z: bridge::log_stream: LogStream (topic: [0x91e3d056fd990b3d93f81c39b9446a584d01db4e9e6660bf3ac5fc081e151b0f]): fetched 0 logs from block 2 to block 10
 INFO 2019-07-30T15:22:48Z: bridge::accept_message_from_main: 0xe06c7c5f85b0811b0df0c5a06251b52b1c55e6209321c4fd970a36ed0bd31165 - 2/4 - checking if the message is already signed
 INFO 2019-07-30T15:22:48Z: bridge::accept_message_from_main: 0xe06c7c5f85b0811b0df0c5a06251b52b1c55e6209321c4fd970a36ed0bd31165 - 3/4 - accepting the message
 INFO 2019-07-30T15:22:49Z: bridge::block_number_stream: BlockNumberStream polling last block number
 INFO 2019-07-30T15:22:49Z: bridge::block_number_stream: BlockNumberStream polling last block number
 INFO 2019-07-30T15:22:49Z: bridge::block_number_stream: BlockNumberStream polling last block number
 INFO 2019-07-30T15:22:49Z: bridge::block_number_stream: BlockNumberStream: fetched last block number 10
 INFO 2019-07-30T15:22:49Z: bridge::block_number_stream: BlockNumberStream: no blocks confirmed since we last checked. waiting some more
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream polling last block number
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream polling last block number
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream polling last block number
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream: fetched last block number 10
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream: no blocks confirmed since we last checked. waiting some more
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream: fetched last block number 10
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream: no blocks confirmed since we last checked. waiting some more
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream: fetched last block number 35
 INFO 2019-07-30T15:22:52Z: bridge::block_number_stream: BlockNumberStream: no blocks confirmed since we last checked. waiting some more
 INFO 2019-07-30T15:22:53Z: bridge::block_number_stream: BlockNumberStream polling last block number
Bridge: polling main to side sign failed

Caused by:
  RelayStream: relaying logs failed

Caused by:
  AcceptMessageFromMain: checking whether 0xe06c1165 was relayed failed

Caused by:
joshua-mir
@joshua-mir
Ah, you're right 😅
@ramxis I am not sure why this would fail at this stage and not the others
joshua-mir
@joshua-mir
But this is a known issue paritytech/parity-bridge#217
Nadeem Bhati
@nadeemb53
@joshua-mir Hi, when I try this command env RUST_LOG=info parity-bridge-deploy --config bridge_config.toml --database bridge.db
I get this error:
INFO 2019-08-02T16:07:03Z: parity_bridge_deploy: Parsing cli arguments
 INFO 2019-08-02T16:07:03Z: parity_bridge_deploy: Loading config
 INFO 2019-08-02T16:07:03Z: parity_bridge_deploy: Starting event loop
 INFO 2019-08-02T16:07:03Z: parity_bridge_deploy: Establishing HTTP connection to main "http://localhost:8547"
 INFO 2019-08-02T16:07:03Z: parity_bridge_deploy: Establishing HTTP connection to side "http://localhost:8546"
 INFO 2019-08-02T16:07:03Z: parity_bridge_deploy: Deploying MainBridge contract
 INFO 2019-08-02T16:07:03Z: bridge::deploy: sending MainBridge contract deployment transaction and waiting for 0 confirmations...
DeployMain: deployment transaction failed

Caused by:
        SendTransactionWithReceipt: fetching last block number failed

Caused by:
        Error(InvalidResponse("Error(\"expected value\", line: 1, column: 1)"), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })
Can you help with this?
joshua-mir
@joshua-mir
@nadeemb53 yep, everyone has this problem atm. There's an open issue on the github repo, but currently nobody is actively looking into a permanent solution - workaround is to deploy the contract manually and not use the bridge-deploy script.
Nadeem Bhati
@nadeemb53
@joshua-mir thanks
Honest Blocks
@HonestBlocks
Hey, having the same issue as above. Which contracts are needed to be deployed manually?
joshua-mir
@joshua-mir
Honest Blocks
@HonestBlocks
@joshua-mir thanks I'll check