Contribute to Open Source. Search issue labels to find the right project for you!

Implement sapling as rust library for transaction generation and validation


Zcash currently has challenges on the horizon with cross platform support, lite clients, and network privacy, as well as the maintainability of a fork of the Bitcoin codebase. Looking longer term, there is the possibility that zcash switches codebases or changes consensus mechanisms. At the same time with sapling’s new crypto, the transaction generation and validation code needs a near complete rewrite for the new protocol. This is an opportunity.

Solutions to the above issues would all be considerably easier if all of the code necessary to generate transactions, including maintaining a copy of the merkle tree and “wallet” code that stores, selects, and assembles notes as inputs to a transaction , was in a separate library distinct from networking and “consensus facing code” (even though tx validation is part of consensus and probably should be a part of the library).

This would make it easy to support lite clients and to switch codebases. It would also make it easier to later produce software that submitted transactions via a mechanism that never touches the P2P network. This is important because both passive and active attacks can fingerprint the P2P network in ways that persist even if connections are over Tor.

It would also allow for improved security by keeping this library in a separate address space or other such countermeasures.

Since the proof generation code is already in rust, the principle code that needs to be redone is for the merkle tree and a “wallet” code

Updated 20/03/2018 22:22 2 Comments

Bridge continiously sending transactions with 'eth_sendTransaction timed out' message during stress testing


This is the issue is the same as but behavior is even worse due to automatic bridge restart implemented in POA bridge.

Network setup: * Home: a PoA testnet (Sokol) * Foreign: Ropsten

There are 1200 deposit transactions sent successfully to HomeBridge contract by a special python script. It took 8 blocks to validate all transactions. …

The bridge discovered part of these transactions, tried to relay some of them, lost the connection and restarted: INFO:bridge::bridge::deposit_relay: got 7 new deposits to relay INFO:bridge::bridge::deposit_relay: relaying 7 deposits INFO:bridge::bridge::deposit_relay: deposit relay completed INFO:bridge::bridge::deposit_relay: got 129 new deposits to relay INFO:bridge::bridge::deposit_relay: relaying 129 deposits INFO:bridge::bridge::deposit_relay: deposit relay completed INFO:bridge::bridge::withdraw_relay: got 0 new signed withdraws to relay INFO:bridge::bridge::withdraw_relay: fetching messages and signatures INFO:bridge::bridge::withdraw_relay: fetching messages and signatures complete INFO:bridge::bridge::withdraw_relay: relaying 0 withdraws INFO:bridge::bridge::withdraw_relay: relaying withdraws complete INFO:bridge::bridge::withdraw_relay: waiting for signed withdraws to relay INFO:bridge::bridge::withdraw_confirm: got 0 new withdraws to sign INFO:bridge::bridge::withdraw_confirm: signing INFO:bridge::bridge::withdraw_confirm: signing complete INFO:bridge::bridge::withdraw_confirm: submitting 0 signatures INFO:bridge::bridge::withdraw_confirm: submitting signatures complete INFO:bridge::bridge::withdraw_confirm: waiting for new withdraws that should get signed INFO:bridge::bridge::deposit_relay: got 113 new deposits to relay INFO:bridge::bridge::deposit_relay: relaying 113 deposits INFO:bridge::bridge::deposit_relay: deposit relay completed INFO:bridge::bridge::deposit_relay: got 710 new deposits to relay INFO:bridge::bridge::deposit_relay: relaying 710 deposits WARN:bridge: Bridge is down with Request eth_sendTransaction timed out, attempting to restart WARN:<unknown>: Sending a response to deallocated channel: Ok([Ok(String("0xc47e8427c9eda913b9749bf0904cd8765b39f5448368194cb7aa4330bbe6a44d"))]) WARN:<unknown>: Sending a response to deallocated channel: Ok([Ok(String("0x4d96f7f39c50dd7b19aac9af708bca450fb6c9fb6b72024c7736d9883614845d"))]) ... WARN:<unknown>: Sending a response to deallocated channel: Ok([Ok(String("0x6b16c0ef9e34d65c4431c4e1e8c043564d53cf3ce440d7ea706164838904e209"))]) The database file was not updated so the restart of the bridge thread caused the same error. INFO:bridge::bridge::deposit_relay: got 951 new deposits to relay INFO:bridge::bridge::deposit_relay: relaying 951 deposits WARN:<unknown>: Sending a response to deallocated channel: Ok([Ok(String("0x9b034a82ebf6306933a35848f9d7b1552ababb8be5774e5501e4802013911a01"))]) WARN:<unknown>: Sending a response to deallocated channel: Ok([Ok(String("0x606b57af0b13dbeddf6b4c16833b0365dace777cc4feee82d2de14c5dde53c45"))]) So, the bridge is continuing to send transactions forever.

Even if the bridge process is killed manually, it is necessary to do manual modification of database but it causes lock of funds on HomeBridge contract side since incomplete amount of tokens is transfered by ForeignBridge contract.

Updated 20/03/2018 09:51 11 Comments

Bridge duplicates transactions after re-establishing connection to Parity


The behaviour to re-establish IPC connection after parity re-run was introduced as part of fix for #22 (

But it caused appearance of minor regression: last set of transactions are being sent twice. Here is the logs from the foreign parity instance before it is killed: 2018-03-10 09:02:53 0/25 peers 87 KiB chain 5 MiB db 0 bytes queue 448 bytes sync RPC: 0 conn, 1 req/s, 175 µs 2018-03-10 09:03:10 Transaction mined (hash e0ac09e000484637fb5af07649d90103edbe6dc48640caa2e81956ac11d88b36) |-------- deposit() invocation 2018-03-10 09:03:10 Imported #6501 fa4a…cf4e (1 txs, 0.08 Mgas, 0.99 ms, 0.77 KiB) 2018-03-10 09:03:20 Transaction mined (hash 7914bbbcc10c105823689628b9815c340eb1a923433b8e5c64ebd8664df31eeb) |-------- approveAndCall() invocation 2018-03-10 09:03:20 Imported #6502 f517…7239 (1 txs, 0.06 Mgas, 1.01 ms, 0.83 KiB) 2018-03-10 09:03:25 Transaction mined (hash 2c6324d205e276170013f8f4450a7379998b4b4fb4b06001d3b296257b84e103) |-------- submitSignature() invocation 2018-03-10 09:03:25 Imported #6503 50b8…91df (1 txs, 0.26 Mgas, 1.12 ms, 1.03 KiB) 2018-03-10 09:03:28 0/25 peers 98 KiB chain 5 MiB db 0 bytes queue 448 bytes sync RPC: 0 conn, 2 req/s, 186 µs

The database file contains the following after that: $ cat ../erc20_db.toml home_contract_address = "0x2ace2268ed7a96713e6cd18e9b2c2ef0c306c22c" foreign_contract_address = "0x5e702ea5d81e14ba807fdd0ac923e811a12bfef1" home_deploy = 6209 foreign_deploy = 6488 checked_deposit_relay = 6218 checked_withdraw_relay = 6503 checked_withdraw_confirm = 6503

As soon as the parity instance is killed and run it produces the following logs: 2018-03-10 09:04:29 Starting Parity/v1.9.2-unstable-0feb0bb-20180201/x86_64-linux-gnu/rustc1.20.0 2018-03-10 09:04:29 Keys path /home/koal/parity/keys/PoA_foreign 2018-03-10 09:04:29 DB path /home/koal/parity/PoA_foreign/chains/PoA_foreign/db/d87bc73279457e60 2018-03-10 09:04:29 Path to dapps /home/koal/parity/PoA_foreign/dapps 2018-03-10 09:04:29 State DB configuration: fast 2018-03-10 09:04:29 Operating mode: active 2018-03-10 09:04:29 Configured for PoA_foreign using AuthorityRound engine 2018-03-10 09:04:30 Public node URL: enode://96b8fa10c0504cb3edb182786fcc8baf6cec3ff5bc4b5f9f82a24c49fe6bd5d09b64a8a2a595ec8d215d0523ec254cf31dda6151cf0a4669edc7bb964fd50af8@ 2018-03-10 09:04:35 Transaction mined (hash 2faba8376df4632da7b4a0ce4cb984b7e51cc90849bf94e8a56a635195253537) |-------- deposit() invocation 2018-03-10 09:04:35 Transaction mined (hash 00da53a569c639617e23854a2fb3e80745690c69230e07df92e7159f1fe1c958) |-------- submitSignature() invocation 2018-03-10 09:04:35 Imported #6504 783d…e97e (2 txs, 4.20 Mgas, 1.15 ms, 1.23 KiB)

and the database file contains: $ cat ../erc20_db.toml home_contract_address = "0x2ace2268ed7a96713e6cd18e9b2c2ef0c306c22c" foreign_contract_address = "0x5e702ea5d81e14ba807fdd0ac923e811a12bfef1" home_deploy = 6209 foreign_deploy = 6488 checked_deposit_relay = 6219 checked_withdraw_relay = 6504 checked_withdraw_confirm = 6504

These transactions are handled properly by the contracts that’s why double-spend does not happen. But it increases expenses of bridge authorities by producing more transactions.

Updated 10/03/2018 23:30 1 Comments

Incorrect error on procedural macros with colons (`::`) in their names


When a procedural macro has a :: in its name, a syntax error is shown even thought the code is prefectly valid rust.


#![feature(proc_macro, specialization)]

extern crate pyo3;

use pyo3::prelude::*;

struct MyClass {
    num: i32,
    debug: bool,
    token: PyToken,


authors = ["konstin"]
name = "mylib"
version = "0.1.0"
crate-type = ["cdylib"]

version = "0.2.5"
features = ["extension-module"]

The following incorrect error is shown in line 7: '!' expected, got '::'

Updated 14/03/2018 20:54 1 Comments



Coach assistant: @probeadd

Sanity checks:

  • [x] GitHub profile photo + detailed profile description


  1. RTEMS
  2. Gentoo
  3. Fedora


Organization Idea Difficulty Technologies & Tools
RTEMS Improve the Raspberry Pi BSP Peripherals C
Gentoo Full Rust Support Medium Rust , Cargo , Ebuild,Bash
Free BSD Integrate MFSBSD into the release building tools Medium C,make,shell


  1. Gentoo - Full Rust Support:Luca Barbato (Contacted)
  2. FreeBSD =Integrate MFSBSD into the release building tools< >
  3. RTEMS - Improve the Raspberry Pi BSP Peripherals Unit: Alan Cudmore

To do: * [ ] Fix issue Ebuild and eselect Gentoo * [ ] Fix issue Rustup and Cargo


  1. Organization: Proposal title
  2. Organization: Proposal title
  3. Organization: Proposal title


  • [ ] Initial contribution to target organization. Link to PR: …
  • [ ] Personal website & portfolio:
  • [ ] StackOverflow profile & activities:
Updated 14/03/2018 05:52 3 Comments

Rust: Support tagged unions


Currently quicktype always emits serde(untagged) for unions.

Serde supports multiple tagged union forms: - [ ] externally - [ ] internally - [ ] adjacently


#[derive(Serialize, Deserialize)]
enum Message {
    Request { id: String, method: String, params: Params },
    Response { id: String, result: Value },
{"Request": {"id": "...", "method": "...", "params": {...}}}


#[derive(Serialize, Deserialize)]
#[serde(tag = "type")]
enum Message {
    Request { id: String, method: String, params: Params },
    Response { id: String, result: Value },
{"type": "Request", "id": "...", "method": "...", "params": {...}}


#[derive(Serialize, Deserialize)]
#[serde(tag = "t", content = "c")]
enum Block {
{"t": "Para", "c": [{...}, {...}]}
{"t": "Str", "c": "the string"}
Updated 16/02/2018 04:46 2 Comments

Use rename_all = "camelCase" for rust instead of renaming each value individually


I have a json schema in which all attributes are in camelCase, so they are renamed to snake_case when generating rust code. Instead of adding a single #[serde(rename_all = "camelCase")] once, all attributes are renamed individually.

So while the expected output is the following,

#[derive(Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct File {
    id: String,
    #[serde(rename = "type")]
    file_type: String,
    name: Option<String>,
    file_name: Option<String>,
    mime_type: Option<String>,

I actually got the following:

#[derive(Serialize, Deserialize)]
pub struct File {
    #[serde(rename = "id")]
    id: String,
    #[serde(rename = "type")]
    file_type: String,
    #[serde(rename = "name")]
    name: Option<String>,
    #[serde(rename = "fileName")]
    file_name: Option<String>,
    #[serde(rename = "mimeType")]
    mime_type: Option<String>,
Updated 14/02/2018 14:47

Bridge must not transact if account balance is less than required for handling transaction


Currently there are two possible situations related to low balance on the account which is used for bridge operations: 1. The account which is used to sign transactions to be addressed by ForeignBridge contract has low balance. So, the bridge is not able to do deposit_relay and withdraw_confirm. 2. The account which is used to sign transactions to be addressed by HomeBridge contract has low balance. So, the bridge is not able to do withdraw_relay.

In both cases bridges hangs silently at the moment of sending transactions and does not proceed with further actions even the operation is intended to be performed in opposite direction (e.g. the bridge hangs at the moment to perform withdraw_relay, so deposit_relay cannot be performed either).

Proposal for changes

Fix the issue - the bridge should not hang if the account has low balance. It should proceed with operations in the opposite direction. It can be achieved by preventing sending transaction if such situation occurs. The error message should be appear in the bridge logs as soon as low balance issue discovered.

Updated 22/03/2018 06:53 9 Comments

Rust improvements

  • [x] Fix invalid JSON in header comments
  • [ ] Optionally emit top-level marshaling functions
  • [x] Improve header comments
    • [x] Only show how to deserialize JSON (no need to show going back to string)
    • [x] Don’t use extra empty lines between statements
    • [x] Use actual top-level type names in sample
  • [x] Optionally omit redundant rename attributes when property name and JSON name match (dense mode)

cc @krk @Phrohdoh

Updated 23/02/2018 03:26 9 Comments

Store the blocks which include deployment/upgrade transactions in the contracts


Currently the block number which includes deployment transaction stored in the database file. This number could be used in recovery scenarios to try reapplying all skipped transactions: go through all the blocks since the block the contract was created and filter deploy/withdraw events. It is also useful to deploy several new bridge instances: every bridge will start filtering events starting from the same block.

In order to simplify deployment of new bridges it could be worth to store this information in the bridge contract instead of storing it in database file: bridge deployment process could get this information from the contracts in order to generate database file with correct checked_deposit_relay, checked_withdraw_relay and checked_withdraw_confirm. So, it will be no necessity to distribute the database file among the target systems.

Proposals for changes

Solidity 1. Introduce deployedAtBlock public field in HomeBridge and ForeignBridge contracts. 2. This field initialized within the contract creation process with the block number.

Rust 1. Change the logic of generating database file as so if there are no checked_deposit_relay, checked_withdraw_relay and checked_withdraw_confirm defined in the file, deployedAtBlock is read from the corresponding contract and the parameters are initialized in the values received from the contract. 2. Remove the code which write home_deploy and foreign_deploy to the database file.

Updated 13/03/2018 07:35 2 Comments

Store gas consumption limits in the bridge contracts


As per the bridge deployment process it is necessary to create configuration file for every bridge instance. There is a section in the configuration file which allows to define gas consumption limits which will be used in the bridge transactions: deposit_relay withdraw_confirm withdraw_relay Since these limits are common for every bridge instance it is redundant to distribute this info among all nodes before deployment begins. Moreover these limits needs to be updated in case of gas consumption changes if the bridge contract is upgraded as per #7. In order to reduce human factor it is worth to update this automatically. Some big constant value for these parameters is not good option to have - it could cause delays in validation since limits will be too big for block validators especially in the Ethereum Foundation network.

Proposal for changes

Solidity 1. Introduce gasLimitWithdrawRelay in the contract HomeBridge. 2. Introduce gasLimitDepositRelay and gasLimitWithdrawConfirm field in the contract ForeignBridge. 3. Setup this parameter as part of bridge contracts deployment process. 4. Introduce ability to change these parameters as part of bridge contract upgrade process as soon as #7 is implemented. Events must be raised in case of gas limit changes.

Rust 1. Change bridge/src/bridge/ to setup gasLimitWithdrawRelay, gasLimitDepositRelay and gasLimitWithdrawConfirm as part of deployment process. 2. Introduce new functionality in bridge/src/bridge/, bridge/src/bridge/ and bridge/src/bridge/ in order to pickup gas limits from the corresponding contract. In order to optimize number of requests made to the blockchain nodes the limits could be re-read as soon as the corresponding event received from the bridge contracts.

Updated 13/03/2018 07:36 1 Comments

No indication if the contract executiton requires more gas than it was specified


Steps to reproduce:

  1. Change the configuration file to reduce gas for deposit_relay to 25400.
  2. Run the bridge with RUST_LOG=debug
  3. Send ether to the HomeBridge contract

When the bridge is trying to send deposit confirmation to the ForeignBridge contract it reports that transaction was sent and deposit completed even it was not handled properly (in my case it was not included in a new block at all):

INFO:bridge::bridge::deposit_relay: got 1 new deposits to relay
DEBUG:<unknown>: [29] Calling: {"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{"data":"0x26b3293f00000000000000000000000037a30534da3d53aa1867adde26e114a3161b2b1200000000
INFO:bridge::bridge::deposit_relay: relaying 1 deposits
INFO:bridge::bridge::deposit_relay: deposit relay completed

Moreover the counter of checked_deposit_relay is increased in the database file. So, the bridge is in incorrect state after sending of such transaction.

Expected behavior

  1. The bridge must track the transactions it is sending and reports if something was wrong with them.
  2. If some relay or confirm operation cannot be completed due to failed transactions the corresponding counter in the database file must not be incremented.
Updated 28/02/2018 09:56

Bridge crashes if a transaction causes `out of gas`


Steps to reproduce:

  1. Change the configuration file to reduce gas for deposit_relay to 20000.
  2. Run the bridge with RUST_LOG=debug
  3. Send ether to the HomeBridge contract

When the bridge is trying to send deposit confirmation to the ForeignBridge contract it crashes and the following appears in the console:

Error(Rpc(Error { code: ServerError(-32010), message: "Transaction gas is too low. There is not enough gas to cover minimal cost of the transaction (minimal: 25368, got: 12000). Try increasing supplied gas.", data: None }), State { next_error: None, backtrace: None })

Expected behavior

The bridge produces an error message to console (which is observable even with RUST_LOG=error) and continues working.

Updated 15/02/2018 04:05

Extend bridge logging functionality


Currently the bridge instance support logging through configuration of the environment variable RUST_LOG. The bridge produces the logs with log level info and allows to get details about JSON-RPC call by setting the level debug.

env RUST_LOG=info ./bridge --config config.toml --database db.toml

example of logs:


env RUST_LOG=debug ./bridge --config config.toml --database db.toml

example of logs:

From examples above it is clear that info level does not provide enough information to investigate possible issues whereas debug level produces lots of lines (not presented in the example above) which are superfluous for investigation of issues related to skipped or missed transactions or hard to use for tracing state of transfers.

Proposal for changes:

It is necessary to extend the logging functionality on ‘info’ level in order to have information hanlded and generated by the bridge instance more transparent. Below is the list of information needed for every type of operation:

  1. deposit_relay

    • tx hash of the transaction used to send funds to the HomeBridge contract, transaction originator, value of transaction.
    • tx hash of the transaction sent by the bridge to the ForeingBridge contract, a reference tx hash (allow to link this transaction to transaction from previous item)
    • information whether respond from the bridge contract (Deposit() event) recieved with the reference tx hash
    • information about other bridges responds with the reference tx hash
  2. withdraw_confirm

    • tx hash of the transaction used to request withdraw from the ForeignBridge contract, transaction originator, value of transaction.
    • tx hash of the transaction sent by the bridge to the ForeingBridge contract, a reference tx hash (allow to link this transaction to transaction from previous item)
    • information whether respond from the bridge contract (event implemented under recieved with the reference tx hash
    • information about other bridges responds with the reference tx hash
  3. withdraw_relay

    • tx hash of the transaction used to inform about signatures collected on ForeignBridge contract with decision if this bridge instance is responsible for relaying the withdraw
    • tx hash of the transaction sent by the bridge to the HomeBridge contract, a reference tx hash (allow to link this transaction to transaction from previous item)
    • information whether respond from the bridge contract (Withdraw() event) recieved with the reference tx hash. This should be included even if another instance of bridge sent information to the HomeBridge contract.
Updated 15/02/2018 02:49

Simplify bridges deployment by creation contracts with the same address


Currently it is assumed that in order to achieve more security at least 3 bridge instances need to be deployed on different independent systems.

The deployment process of several bridges now is the following: 1. Configure and run the first instance of the bridge. 2. Distribute the database toml-file created by the first bridge to other nodes. This file contains addresses of bridge contracts deployed by the first instance, so other instances needs to work with these contracts as well. 3. As soon as the database file is the same on every nodes, they could be run.

Proposal for changes:

Simplfy deployment process with creation of the bridge contracts with the same address in Home and Foreign networks. It could be achived by using the same address and the same NOnce for the contracts deployment in both networks. Since in most cases it requires to create new account with new keystore/private key, so, there is a neccessity to manage this keystore/private key. That’s why another approach could be to use deployment transactions with hardcoded signature as it is implemented here: (ability to do this in different networks confirmed in

It will allow: * generate the database toml-file easily as part of automatic deployment by passing one address to the deployment scripts. * if the bridge contracts are extended with ability to return the block number which deployment transaction is included in, deployment script will extract this information from the contracts and use it for the database toml-file generation.

Automatic generation of the database file and changes in the contracts will be covered in separate issues.

Changes required:

  1. Modify cli/src/ to support command deploy to send contracts deployment transactions to the networks and exit. The database toml-file must be generated after the command execution.
  2. Modify bridge/src/bridge/ to deploy contracts with the same address.
Updated 11/02/2018 07:28

(Epic) Reverse bridge logic in order to do all expensive confirmations on HomeContract side



The basis of the bridge operations is events EVM sends as part of contract execution. Every bridge instance is looking for new events and as soon as an event appears after transaction applying from a new block, the bridge performs an action.

For example, when an account sends ether to the brigde contract in the Home side of the bridge (the left side), Deposit events is produced. The bridge instance catches this event and creates transaction on the Foreign (right) side to invoke deposit() method of the bridge contract. This transaction is considered as a bridge signature under the fact that some user transfers asset to the Foreign network.

<a href=“” target=“_blank”> <img src=“” alt=“bridge deposit (flow with 3 bridges in action)” width=“550” /> </a>

In order to achieve availability and reliability, there are more than one bridge instances (N). During these bridges configuration it is settled that just subset (M, M <= N) of them is enough to transit the state between two networks. So, if M bridges confirmed the same state transition operation (deposit), this state committed on the opposite side of the bridge:

<a href=“” target=“_blank”> <img src=“” alt=“bridge deposit (simple flow)” width=“750” /> </a>

This is a basic scenario which is enough to transite state between two EVM-based networks. The maximum (for the third bridge) gas consumption of deposit operation is about 90000.

The use case considered by parity-bridge (, commit ceaf22f) is to connect Ethereum Foundation (Home side) and a private PoA networks (Foreign side). So, it is assumed that we need to keep as cheap as possible transactions on the Home side whereas consumption of the gas on the Foreign side does not make much sense. This is due to the reason that most probably bridge instances are managed/supported by owners of the PoA network so almost infinite resources could be spent to maintain transactions from bridges within the PoA network.

That is why the original development of parity-bridge is focused on the reduce number of transactions and gas consumption for operations made on the Home side of the brige. In order to transit the state from the Home to the Foreign network three bridges will send three transactions. And only one bridge is being chosen to perform state transition from the Foreign side to Home.

It becomes posisble owing to the architecture when confirmations of bridges to transfer the state are collected on the Foreign side (remember that it costs nothing) and as soon as needed number of confirmation gathered the bridge which sent the latest confirmation is responsible for forwarding all signatures (which are part of the confirmations) to the Home side.

<a href=“” target=“_blank”> <img src=“” alt=“bridge withdraw (flow, 3 bridges)” width=“850” /> </a>

The procedure to confirm the state transition (submitSignature) is the most expensive one. It consumes about 270000 gas (if it was sent to provide a final signature) since requires lots of mathematical operations and use the contract storage extensively.

Here is the list gas consumption for all operations performed by bridge: Handling deposit() on the Foreign side (deposit_relay) = 90861, every bridge instance Handling submitSignature() on the Foreign side (withdraw_confirm) = 265380, every bridge instance Handling withdraw() on the Home side (withdraw_relay) = 72444, one bridge instance

Relatively huge gas consumption is the only the reason why patity-bridge is not recommended to be used with Ethereum Foundation network in the right side: the meaningless from the state transaction confirmation operation will cost ~5 USD (exchange rate 1000 USD per 1 ether). But cases when a PoA network is on the Home side and the Ethereum Foundation network is on the Foreign side make sense since they allow to split transactions traffic between two networks which could have positive effect on network performance and transactions fees.

Proposal for costs optimization

From the analysis above it is evident that most costly transactions happens on the right side of the bridge. So, if Ethereum Foundation network is there so it will not be cost effective to send several transaction to confirm the deposit and several transaction to confirm the withdraw.

It means that all operations for confirmation should happens on the left side of the bridge and it equals of mirroring handling of confirmation for the current implementation: 1. As soon as a user deposits coins, validators confirmations must be gathered on the left side of the bridge. It will be called deposit_confirm. 2. When last confirmation received, one validator (one which sent the final confirmation) is responsible for forwarding the confirmation to the right side: deposit_relay. 3. If a user sends request to exchange tokens to coins, the Withdraw event is handled and every bridge instance sends the confirmation directly to the left side of the bridge. It is withdraw_relay.

<a href=“” target=“_blank”> <img src=“” alt=“PoA CTT bridge deposit (3 bridges)” width=“850” /> </a>

<a href=“” target=“_blank”> <img src=“” alt=“PoA CTT bridge withdraw (3 bridges)” width=“850” /> </a>

Changes required:

  1. Optimization of the ForeignBridge contract:
    • remove submitSignature(), signature() and message();
    • remove the corresponding maps keeping information about signatures;
    • rework deposit() to work with list of signatures similarly to withdraw() of the original HomeBridge contract;
    • consider to have the code to cover costs of the bridge (isMessageValueSufficientToCoverRelay(), getWithdrawRelayCost() and estimatedGasCostOfWithdraw)
  2. Modification of the HomeBridge contract:
    • rework withdraw() to accept signatures directly from bridge validators similar to deposit() method on the original ForeignBridge contract.
    • there is no need any more to cover costs of the bridge on the Home side so isMessageValueSufficientToCoverRelay(), getWithdrawRelayCost() and estimatedGasCostOfWithdraw must be removed.
    • introduce submitSignature(), signature() and message() and corresponding maps to keep information about signatures similarly to the original ForeignBridge contract.
  3. Rework bridge/src/bridge/ to send withdraw() to the HomeBridge contract as soon as Withdraw event appeared on the Foreign side. Every bridge instance should invoke this method simiarly deposit() of the original HomeBridge contract.
  4. Rework bridge/src/bridge/ to wait for CollectedSignatures and forward deposit with the list of signatures to the ForeignBridge contract.
  5. Rename bridge/src/bridge/ to bridge/src/bridge/ and modify it as so Deposit event is being waited from Home side and submitSignature() is invoked by every bridge instance. The corresponding changes must be made in bridge/src/bridge/ in order to run the confirmation module.
  6. Modify bridge/src/ and bridge/src/bridge/ to not track checked_withdraw_confirm in the database and update checked_deposit_confirm instead.
  7. Modify bridge/src/ to
    • get rid of options transaction.withdraw_confirm.gas, transaction.withdraw_confirm.gas_price.
    • introduce options transaction.deposit_confirm.gas, transaction.withdraw_deposit.gas_price.
Updated 13/02/2018 10:42 2 Comments

(Feature) Add support to communicate with networks by RPC


Currently parity-bridge assumes that full nodes of networks are configured on the same system where the bridge is run. Therefore it communicates to the nodes by using IPC. This cause several limitations: * Requirements to the network bandwidth and the system performance/capacity should be quite high: the system must have enough space to keep two blockchains and must verify all new appeared blocks. So, it means that maintaining one bridge instance withing the cloud could be quite expensive solution. * The availability of the bridge software depends on the reliability of the particular Ethereum network client software. If an Ethereum client is not operaing (e.g. it crashes accidentally), the bridge software is not operating as well.

The way to avoid these limitations is to introduce ability for the bridge to communicate to full nodes through RPC. It will increase responsiveness of the bridge slightly which should not cause big issues due to the current nature of transactions confirmation mechanism used in the blockchain (there is no strict guarantee of a transaction inclusion into the next block).

Changes required:

  1. Change bridge/src/ to
    • support the configuration parameters rpc_host and rpc_port;
    • introduce the parameter keystore to keep the path to the directory where files with private keys are stored, this parameter is not subordinated to any section of the configuration file since it is common for entire bridge;
    • extend sections [home] and [foregin] with parameter password which contains path to the file with password to decrypt the corrsponding key file to extract the private key of the account responsible for signing transactions related this side of the bridge.
  2. Change bridge/src/ to provide the ability to connect through RPC. The following logic of connection channel selection should be implemented: if the parameter ipc is specified the IPC connection must be setup even if rpc_host is specified. If rpc_host specifed but there is no configuration for the parameter rpc_port the port 8545 is used by default.
  3. Extend the functionality of sending transactions to sign them by using private key of the corresponding account and sending them through sendRawTransaction functionality. Encrypted key for the bridge authority account must stored in a separate file. This approach requires to use network id of the corresponding blockchain and NOnce (number of operation) of the corresponding account.
  4. Introduce new parameters home_network_id, home_account_nonce, foreign_network_id and home_account_nonce in the database in order to get rid of requests to the IPC/RPC nodes to track network id and NOnce required to sign transactions. A new paramter authority_keystore must keep a path to the keystore file with the private key of the bridge authority. This parameter should not belong any node in in the configuration file.
Updated 28/02/2018 18:09 2 Comments

load the real RTS if it is built and in play


How best to make the loading of the real RTS smooth…

Here are some options - A. look to see if target/debug/backend.dll exists in an assumed location, (assume that sky-rts is cloned into the same dir as SCAII). If that file exists, it will load it using the correct InitAs message. B. require passing an argument into replay that is the path to the dll - a more generic approach if we have other backends in the future.

I also realize now I’ll have to do some refactoring in either case to allow the tests and “live” mode to coexist.

I’m leaning toward B. Thoughts, Zoe? (assigning to Zoe for review)

Updated 09/02/2018 03:55 2 Comments

rust 1.8.0 on osx does not work


This issue has been observed on several pull requests to servo/heapsize library in last few days.

pr: - - -

All of these builds fail only on osx where rust 1.8.0 is installed

<img width=“976” alt=“screen shot 2018-01-24 at 11 05 59” src=“”>

The build error always looks the same:

# Host Database
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##   localhost Traviss-Mac-496.local broadcasthost
::1             localhost
Fix WWDRCA Certificate
Unable to delete certificate matching "0950B6CD3D2F37EA246A1AAA20DFAADBD6FE1F75"security: AppleWWDRCA.cer: already in /Library/Keychains/System.keychain
$ rvm use
Using /Users/travis/.rvm/gems/ruby-2.4.2
/Users/travis/.travis/job_stages: line 436: yarn: command not found
0.62s$ git clone --depth=50 servo/heapsize
Cloning into 'servo/heapsize'...
remote: Counting objects: 380, done.
remote: Compressing objects: 100% (194/194), done.
remote: Total 380 (delta 169), reused 351 (delta 146), pack-reused 0
Receiving objects: 100% (380/380), 67.66 KiB | 3.76 MiB/s, done.
Resolving deltas: 100% (169/169), done.
$ cd servo/heapsize
0.32s$ git fetch origin +refs/pull/93/merge:
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 3), reused 5 (delta 3), pack-reused 0
Unpacking objects: 100% (6/6), done.
 * branch            refs/pull/93/merge -> FETCH_HEAD
$ git checkout -qf FETCH_HEAD
Installing Rust
36.19s$ curl -sSf | sh -s -- --default-toolchain=$TRAVIS_RUST_VERSION -y
info: downloading installer
info: syncing channel updates for '1.8.0-x86_64-apple-darwin'
info: latest update on 2016-04-12, rust version 1.8.0 (db2939409 2016-04-11)
info: downloading component 'rustc'
 37.1 MiB /  37.1 MiB (100 %)   5.2 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 50.3 MiB /  50.3 MiB (100 %)   9.9 MiB/s ETA:   0 s                
info: downloading component 'rust-docs'
  5.4 MiB /   5.4 MiB (100 %)   1.3 MiB/s ETA:   0 s                
info: downloading component 'cargo'
  2.5 MiB /   2.5 MiB (100 %) 882.6 KiB/s ETA:   0 s                
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'rust-docs'
info: installing component 'cargo'
info: default toolchain set to '1.8.0'
  1.8.0 installed - (timeout reading rustc version)
$ export PATH=$HOME/.cargo/bin:$PATH
$ rustc --version
rustc(1098,0x7fffa71e83c0) malloc: *** malloc_zone_unregister() failed for 0x7fffa71de000
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on:
The build has been terminated

1.8.0 used to work in the past, but it’s hard to tell when it got broken. The last successful build of this library on osx with 1.8.0 happened on 18 Oct 2017.

Updated 27/01/2018 01:17 3 Comments



<b>svenstaro/genact</b><br> <blockquote>Pretend to be busy or waiting for computer when you should actually be doing real work! Impress people with your insane multitasking skills. Just open a few instances of genact and watch the show.</blockquote> Tags: github, joke, rust<br> Added at January 20, 2018 at 11:39PM via Pocket<br>

Updated 22/01/2018 10:13 1 Comments

rust: Revisit Buffer type?


I tried to introduce a Buffer type (#116, reverted in #118) for the in-place API which takes care of slicing the message and MAC portions of the in-place buffer for you, in hopes of improving the ergonomics and abstracting over the odd way in which the plaintext portion of a message starts in the middle of the buffer instead of the beginning.

My original goal was to have Buffer wrap a &[u8] and use Into<Buffer> to bound the buffer type passed into the in-place APIs, allowing the caller’s choice of either a byte slice or a Buffer to be passed.

Unfortunately, this doesn’t work because we’d need to coerce a reference into an owned type. We could do that with an unsafe pointer cast, but I was hoping to avoid that, so I experimented with having Buffer<T> wrap an owned type with bounds AsRef<&[u8]> and AsMut<&[u8]>, allowing it to wrap either Vec or fixed-sized arrays, and then just passing &Buffer<T> to all the in-place APIs (i.e. mandating use of Buffer instead of allowing either a buffer or a slice).

All of that was slightly annoying but the owned type seemed to be working ok. That was until I realized AsRef and AsMut, in a pre-const generics world, are only implemented for fixed-sized arrays up to 32, which was a showstopper.

I think having a Buffer type is still worth investigating, as the present in-place ergonomics still leave quite a bit to be desired. I think it might be worth investigating the unsafe pointer cast option, although it would violate Miscreant’s “all safe Rust” selling point.

Updated 06/01/2018 19:45

[Sapling] Specify and implement the signature scheme for spend authorization


We intend to use an EdDSA signature on the Jubjub curve to authorize spends. The original Ed25519 scheme made some assumptions might not be applicable to the Jubjub curve.

Generalised EdDSA is specified in the paper EdDSA for more curves, and standardized as RFC 8032. It requires a hash function with output size 2b bits, where 2<sup>b-1</sup> is greater than the field size. For Jubjub, b = 256, so the obvious choice is BLAKE2b. For the “pure” version of EdDSA that doesn’t prehash the message, this would be called PureEdJubjub-BLAKE2b. The RFC specifies additional constraints on the input to the hash function (the dom{2,4} byte and context) that are not present in the paper.

To close this ticket, * [ ] choose all 11 parameters mentioned in the paper * [x] decide how to resolve any incompatibility between the RFC and the paper * [ ] nail down options for verification (strictness of parsing, whether cofactorless verification is used, whether low-order points are rejected) * [ ] add PureEdJubjub-BLAKE2b to the protocol spec * [ ] implement it * [ ] publish test vectors (including signatures rejected for various reasons)

Updated 13/01/2018 07:43 5 Comments

Use ciphersuite strings to select ciphers?


The test vectors presently use the following ciphersuite strings:

    • Key Agreement: X25519
    • KDF: HMAC-SHA-256
    • Symmetric Cipher: AES-128-SIV
    • Key Agreement: X25519
    • KDF: HMAC-SHA-256
    • Symmetric Cipher: AES-128-PMAC-SIV

However, none of the existing XSTREAM implementations accept these as arguments, but instead take an AES-SIV versus AES-PMAC-SIV string which is passed directly to Miscreant (where applicable).

For the Rust implementation in particular, it would be nice to have object safe traits for STREAM which allow us to use either STREAM or XSTREAM via a trait object, and in particular to select the stream encryptor type to use based on a string.

Updated 05/01/2018 02:52

[Rust] Server starting with only first word of "server.hostname" parameter


I’ve configured a server to launch as My Rust Server, but it is simply found in-game as My.

Here’s the Hastebin:

From the Hastebin:

Command-line Parameters
./RustDedicated -batchmode +server.ip * +server.port 28015 +server.tickrate 60 +server.hostname "My Rust Server" +server.identity "rustserver"  +server.maxplayers 50 +server.worldsize 5000 +server.saveinterval 300 +rcon.web 1 +rcon.ip * +rcon.port 28016 +rcon.password "********" -logfile "/home/*/rust/log/server/rustserver-game-2017-10-29-01:19:37.log"

It seems like a weird issue; I used to host a Rust server from a canned gameservers hosting provider, and the server.hostname parameter worked fine.

Updated 07/01/2018 17:43 2 Comments

Send adaptive program queries to Agent


We need to be able to query the agent for feedback on a game state during replays for explanation stuff. This will be evolving a lot, my first intuition is that we should provide some simple visualization primitives (more high level than what the backend uses) like “pie chart”, “heatmap”, “highlight entity” etc. We need to take care to not reinvent an entire plotting package.

Since we’re using JS, something like bokeh is out, but we may be able to find some nice JS plotting libraries to lighten the load. (Which is a shame, it’d be nice to send rendered graphs from bokeh, they look quite nice).

Depends, minimally on #14, #16, #17, #18 + some API and protobuf consideration

Updated 08/01/2018 22:45 2 Comments

Rust: Support external crates


I was told that support of Rust was experimental so I can expect hickups and that’s understandable but currently it seems external crates are not supported. Since you can’t really do much in Rust without external crates, it basically means that Meson doesn’t really support Rust. IMO until this issue is addressed in some way, support for Rust shouldn’t be advertised at all.

Updated 21/03/2018 21:01 31 Comments

ensure all transitive rust dependencies are fetched via our depends system.


build fail with librustzcash while using a proxy. affected repository:

output: cd /home/riordant/Documents/Project/zcash/depends/work/build/x86_64-unknown-linux-gnu/librustzcash/0.1-2078cca28b9/.; PATH=/home/riordant/Documents/Project/zcash/depends/x86_64-unknown-linux-gnu/native/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin cargo build --release Updating registry `` warning: spurious network error (2 tries remaining): [12/-2] [7] Couldn't connect to server (Unsupported proxy scheme for '') warning: spurious network error (1 tries remaining): [12/-2] [7] Couldn't connect to server (Unsupported proxy scheme for '') error: failed to fetch ``

zcash version: v1.0.8

  • OS name + version: Ubuntu 16.04.2 (VM)
  • RAM: 8GB
  • Disk size: 39GB
  • Linux kernel version (uname -a):Linux riordant-virtual-machine 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
  • Compiler version (gcc -version): gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Updated 17/03/2018 16:30 8 Comments



Still needs to be heavily refactored. How to encode number of instruction in type / have function arities depend on that?

Updated 06/03/2018 09:48 1 Comments

Fork me on GitHub