raiden-network / raiden Goto Github PK

ExchangeManager, ExchangeTask, ExcchangeRequest

follow up to #8

• create testdata
• test

parent #54

Add support for easy profiling
ideally the continuous integration would notify if a commit slows the system down

The raiden node needs to keep updated about changes to the (global) state by listening for Events.

Generalize the payment channels into state channels that can be used by individual applications.

Protocol Draft:

Envelope

Raiden envelope for payment transfers is comprised of:

• signature
• nonce
• transferred amount
• locksroot

[ 65bytes signature | 8bytes nonce | 32bytes transferred amount | 32 bytes locksroot | ... arbitrary length data ]

Fields usage

The nonce is a non-global monotonically increasing value used to determine the message ordering. By non-global it's meant that each participant increments it's own nonce without synchronizing with it's partner, this removes a series of synchronization problems. The value must be non-zero (zero is used by the smart contract as a null value).

• raiden requires not only a monotonically increasing value, but a value increment sequentially (+1).
• transferred amount is not sufficient to define message order because not all messages change it's value.

The transferred amount is a monotonically increasing value used to determine the balances of each participant, the value must be monotonically increasing because this property only allows each party to give token to the partner and not take any.

• One's resulting balance is defined as initial_balance + received_amount - transferred_amount where the received_amount = latest_received_transfer.transferred_amount and transferred_amount = latest_sent_transfer.transferred_amount

The locksroot is the root node of a merkle tree encoding all the unexpired & unclaimed locks at the moment the channel is closed, this is used as a proof that a given lock was pending and valid to allow claiming it's value inside the settle_timeout window, this may be done if secret is learned and the lock has not expired yet.

Depends on: #292
A recoverable signature to prove the validity of the message, the signature is defined as ecdsa_recoverable(privkey, nonce || transferred_amount || locksroot || contract_address).

• the contract_address is the smart contract holding the tokens from both participants in escrow, used to prohibit settling a channel with an invalid message:
  • that Bob reuses a transfer from Alice from a closed channel among them to settle a new channel.
  • that Charlie reuses a transfer from a different channel, eg. among Alice and Bob.
  • this is an alternative implementation to the nonce ranges, the benefit is that all bits from the message may be used.
• An alternative signature would be comprised of ecdsa_recoverable(privkey, packet_data[65:] || contract_address), where the signature can also be used to validate the data in the envelope.

Base solidity library

Basic struct must contain:

• closed block number
• settle timeout
• both participant addresses
• the envelope data for a transfer from each participant

Alternatives

Fixed vs. "dynamic" settlement period

The current NettingChannelLibrary has a fixed settlement period, this is used for dispute resolution and for unlocking locks unclaimed at the time the channel was closed, as a consequence the NettingChannelContract settlement period is an upper bound for the lock's expiration timeouts and a limit on the number of hops that can participate in a mediated transfer.

An alternative implementation removes the settlement period of the NettingChannelContract and add it to the message envelope, where the current highest expiration of all locks is used and signed along side with the merkleroot, and the smart contract will only allow settlement after this latest settlement period has elapsed plus a reveal timeout.

Benefits of fixed settlement:

• smaller envelop size in bytes

Benefis of dynamic settlement:

• unbound number of hops (at the protocol level, the application might want to use a configuration for it)

Reported by @ryepdx in the gitter channel.

The receiving logic (first block), should increase local balance and decrease the partner balance.

        if hashlock in self.locked:
            amount = self.locked.get(hashlock).lock.amount
            self.balance += amount
            self.partner.balance += amount
            self.locked.remove(hashlock)
        if hashlock in self.partner.locked:
            amount = self.partner.locked.get(hashlock).lock.amount
            self.balance -= amount
            self.partner.balance += amount
            self.partner.locked.remove(hashlock)

Support persistance of channel states.

While installing on El Capitan, using virtualenvwrapper I got this error:
fatal error: 'openssl/aes.h' file not found

I fixed this by installing with:

env LDFLAGS="-L$(brew --prefix openssl)/lib" CFLAGS="-I$(brew --prefix openssl)/include" python setup.py install

According to: pyca/cryptography#2350

Travis is currently failing since solidity is not installed

ban == not init a transfer involving node X

X seem to be unresponsive. Could be a network glitch, but also X gone byzantine. Therefore we should be him say 10 minutes, then try again, if not good, double the ban, etc. if ban > X, close channel.

Do Solidity libraries exist that can de/serialize messages (in eg. rlp or ABI encoding) sent to smart contracts?
If not, how can we solve this problem?

follow up to #8

• test unlocked transfers
  depends on #52

currently they receive objects in their signature (e.g. close). in solidity they'll receive something that fits the contract ABI.

parent #54

switch serialization to msgpack, especially:

https://github.com/vsergeev/u-msgpack-python
with this extension:

import umsgpack

def _pack_map(obj, fp):
    if len(obj) <= 15:
        fp.write(struct.pack("B", 0x80 | len(obj)))
    elif len(obj) <= 2**16 - 1:
        fp.write(b"\xde" + struct.pack(">H", len(obj)))
    elif len(obj) <= 2**32 - 1:
        fp.write(b"\xdf" + struct.pack(">I", len(obj)))
    else:
        raise umsgpack.UnsupportedTypeException("huge array")

    for k in sorted(obj.iterkeys()):
        umsgpack.pack(k, fp)
        umsgpack.pack(obj[k], fp)

umsgpack._pack_map = _pack_map

check:

how do nested objects work
how to serialize w/o copying too often
how to deserialize to objects without copying the data (e.g. set dict?)

https://github.com/brainbot-com/raiden/blob/master/raiden/smart_contracts/registry.sol#L22-L33

• For the initiators
  • Reveal or not the secret, depending on the transfer amount reported by the target.
• For the mediators:
  • Decrease the lock.amount equal to it's fee amount
• For the target
  • Inform the initiator how much token the receive transfer (Done with the secret request message)

Timeline

The PFS team relies on this implementation before it can incorporate fees into its routing algorithms. A basic implementation until mid-March 2019 would be good.

• DirectTransfer might need a expiration field
• Take into consideration the MediatedTransfer and CancelTransfer expiration in the netting contract

We are using nonces to:

• partially sort transfers
• detect out-of-sync messages
• avoid replay attacks

We might need to have a per channel nonce, that is shared among all messages exchange between the two nodes.

translate https://github.com/heikoheiko/raiden/blob/master/raiden/contracts.py .

Hey guys - have you got a chat channel or some info pages or something we can take a look at ?
We're looking at using and contributing to Raiden for an internal payments network we've been tasked with building - please let me know how to get in touch.

parent #54

Depending on the value of self.asset, messages could be re-applicable between two instances of the same state channel (between=[Alice, Bob], asset=BBCoin). Given that:

• Alice and Bob opened+settled channel for BBCoin yesterday AND
• Alice and Bob open a new channel for BBCoin

If self.asset resolves to the same value, there seems to be no value unique to the current instance, i.e. yesterdays messages could be valid in today's channel.

So: either the asset-address needs to be unique, or we should include the state-channel address in signed transfer messages.

See:
https://github.com/brainbot-com/raiden/blob/master/raiden/messages.py#L291
https://github.com/brainbot-com/raiden/blob/master/raiden/messages.py#L394

As an initiator, the expiration of a transfer-lock is critical for a transaction to succeed but the path is not known beforehand.
The maximum valid lock-expiration is dependent on the settle_timeout of the first channel a node chooses for a MediatedTransfer - a very small initial lock-expiration time won't allow the transaction to succeed.
The 'InitMediatedTransferTask' should spawn MediatedTransfers and wait for confirmation or timeout,
then it should alter timeout/expiration-parameters accordingly.

• create commandline argument parsing for node startup see specs
• start interactive repl
• document usage for manual transfers

parent #61

Every node should log its transfers to a journal.

The Raiden Application is a DApp. It accesses the Ethereum network using the Ethereum API. It provides services through its websockets API.

Sub Tasks:

• #9
• #10
• #11

... to support callbacks in raiden_service.API.transfer

to enable user notification of transfers success.

Consider what is a proper bloom filter for the secret revealed events (or if it is required at all)

We need to make sure that the funds can be recovered in these scenarios:

• A deposits but B doesn't, A must be able to close the channel and reclaim it's deposit.
• A deposits and thinks that B did not, B tries to deposit after the channel was closed by A, the deposit should fail

duplicate of #157 #172 ?

parent #54

And make sure that an asset exists before creating a channel manager for a given asset.

parent #54

translate https://github.com/heikoheiko/raiden/blob/master/raiden/contracts.py to hydrachain native contracts.

create an abstraction layer for access to the blockchain and channel states. needs to be integrated asynchronously. maybe work on a cached copy of the channels and use event listeners to get updates from ethereum using json-rpc.

parent: #54

Add missing functions:

channelManagerContract

• A function that return a list of all existing channels [(addr1, addr2), (addr3, addr4), ...]
  • https://github.com/brainbot-com/raiden/blob/master/raiden/network/rpc/client.py#L165

nettingChannelContract

• A function to get the participants deposits and addresses
  • https://github.com/brainbot-com/raiden/blob/master/raiden/network/rpc/client.py#L188

Measure the impact of the serialization on performance.

Related issue: #14

We don't want to sign all messages because ecrecover is an expensive operation, specially we don't want to sign the Delivered messages because that would double the number of signatures, without encryption that means that an Delivered message can be easily forged.

A forged Delivered's can be used to make a channel unusable and maybe to steal some asset.

• To make a channels unusable an Delivered for a DirectTransfer or Secret message is sufficient, since the sender would update it's state while the partner won't.
• To steal some asset a MediatedTransfer is required, ABC, B would need to intercept the RevealSecret messages and make sure that C don't receive it until the the BC lock expires, then it can settle the transaction AB on chain with the secret learned from the intercepted message (#473).
  • This is still possible with the Secret Registry iff the lock expiration changes, and this is possible since the settle timeout is not enforced to be constant through out the network

With an encryption scheme faster than ecrecoverable signatures we can drop the signatures from the messages that are not exposed to the smart contract (messages that are signed only to inform us about the sender, eg. SecretRequest, TransferTimeout, etc.)

need tox.ini etc.

All transfers that occurred in the same channel need to be sortable in respect to their creation/acceptance, as a consequence a total order is required among the transfers in a channel.

This is required for the correct settlement of conflicts, since only the very last transaction's balance should be take into account.

Demonstrating IoT + mobile compatibility

Well known and using an ARM CPU
https://en.wikipedia.org/wiki/ARM_architecture#Market_share

The signed MediatedTransfer message and also Locks need to be deserializable in Solidity.

see also: #21

follow up to #8

• direct transfer
• mediated transfer

Expose the API of raiden to external clients.

General API Spec:

• Setting up the initial connection to the raiden network should be possible manually (by opening channels and depositing into them from single API methods)

• Additionally we want to provide a (semi-)automatic setup to the network from given configuration-parameters
  (e.g. based on available assets, so that the node takes care of an optimal connectivity to the raiden network by opening and depositing into channels without any additional considerations from the user)

• API calls and responses should include a specification of the API-version (up from v1.0), so that the API is future-proof. The app has to include all versions of the API in the future.

• MvP: this version of the API needs to provide all neccessary tools to make it possible to build a Wallet style UI (issue #285)

Functionality

add following methods to raiden-service.RaidenAPI:

• query_endpoint(raiden_address) - for light clients
• register_endpoint(endpoint, signature)
• get_channel_info() - retrieve the timeout, deposit, etc

let the caller decide if the called method should be executed asynchronous or waiting
(== gevent.Greenlet.wait())

• asset_swap(..., wait=<bool>)
• expect_asset_swap(..., wait=<bool>)
• transfer(..., wait=<bool>)

The asynchronous method should be the default option,
but when calling via REST the waiting method should be default.
That's because in e.g. JavaScript one can work easily with Promises.

Protocol:

• Endpoints of all methods in the raiden_service.RaidenAPI are accessible through http-requests and are structured complying to a RESTful-pattern. Resources are kept minimal:
  • (e.g. on /api/channel
    -GET - get channel info,
    -POST - open channel,
    -DELETE - close channel,
    -UPDATE - deposit to channel )
• All http-requests (-> client-initiated) are 'blocking' and at least include information about the success of the call in their response message. That way we don't have to work with callback-ids on the client side (see #280 ) but rather can work with promises.
• For non-client initiated actions (e.g. incoming transfers, opened channels, channel closing etc.) there will be the emission of events from the node to the client
• Filtering of the events will be done on the client side, so all events will be put in a FIFO-queue and sequentially forwarded to the client
• We assume that only 1 client per node is connected
• Events and responses will be serialized to JSON, 'difficult' data encoding will be reused from the Ethereum protocol (pyethapp/pyethereum) where possible
  (e.g. hex encoding for addresses)

Transport:

• Method-calls: TCP (http-requests)

• Events: the client can choose between

  1. TCP (polling http-requests)
  2. TCP ( long-polling; 'fake' push notifications)

• The interface for the API has to be uniform, independent of the chosen transport-layer

Tasklist

• Expose blockchain events in the REST api
• Add http endpoint for exchange task
• Expose Raiden Rest API at Raiden start
• Expose Raiden internal events from the REST API --> #594 #466
• Add rpc endpoints for connect and leave of token networks

Tasklist

• Measure throughput of a node sending mediated transactions through N channels without mediation.
• The benchmark script must accept an argument for the minimum value for the TPS, and if the given value is not reached it should exit with a status of 1
  • The benchmark must be added to the build with the minimum value for TPS set.