Ethereum - golemfactory/golem-rd GitHub Wiki

Lightwallet

Light wallet in Go On 30/06/2016, the public test phase for the Ethereum Light Client has started.

Other Ethereum backends

Micropayments

Payments channels

Jeff Coleman: State chanells (...) interactions which could occur on the blockchain, but instead get conducted off of the blockchain, without significantly increasing the risk of any participant.

Payments channels are usually useful, when two parties have many succeeding micropayments between them, eg. paying for each downloaded kB of data (between downloading user and service provider), for accepting forum post (between forum owner and moderator), for clicking on ads on one's website (between advertiser and website owner). There are three main steps:

  1. Creating a channel (with locking escrow for both parties).
  2. Making transactions off-chain
  3. Submiting final state to blockchain.

Difficulties: someone must be only to send appropriate state (if other side tries to submit the old one), it may be the user or someone else who has access to signed off-chain state updated.

Peter Todd: Micropayment channels can be extended to arbitrary numbers of parties using a nearly completley untrusted hub, greatly decreasing transaction fees and greatly increasing the maximum number of financial transactions per second that Bitcoin can support.

Using a nearly completely untrusted hub we can allow any number of parties to mutually send and receive Bitcoins instantly with near-zero transaction fees. Each participant creates one or two micropayment channels with the hub; for Alice to send Bob some funds Alice first sends the funds to the hub in some small increment, the hub sends the funds to Bob, and finally the hub gives proof of that send to Alice. The incremental amount of Bitcoins sent can be set arbitrarily low, limited only by bandwidth and CPU time, and Bob does not necessarily need to actually be online. The worst that the hub can do is leave user's funds locked until the timeout expires.

Gnosis must use off-chain transaction to allow bets on short-time predictions.

HydraChain

HydraChain is an extension of Ethereum, that allows to create private and consortium chains. It uses Ethereum API. It has its own byzantine tolerant consensus protocol that doesn't use proof-of-work but depends on register set of validators. Validatators are voting for blocks, their decision is final (there are no forks or reverts). Block times are very short but new blocks are produced only when needed (there are new transactions).

No more than 1/3 of validators in the protocol must be byzantine. The proposer of a block is byzantine (by round-robin algorithm). Voting is done in rounds. In a given round proposer is creating a new block and validators are voting for that block. Round may end when 2/3 of validators have voted.

Hydrachain seems to be created for small private blockchains when all voting nodes and their number is well known to all nodes. It doesn't seem to fit to dynamic high scale network like Golems. It may be used for tests but not in a live version of a network.

Lightning network

Bitcoin instant, high-volumen anyone-to-anyone micropayments system. Two users don't have to have micropayment channel opened between them to make payments, they just need to find a path of opened channels between them. It uses new bitcoin op code: OP_CHECKLOCKTIMEVERIFY (bitcoin fork required).

Problem: "finding route", how to this effectively is ignored in papers.

There are currently few implementation, but all of them are in an early stage. Hashplex current implementation is in its infancy. There are 4 parts: server, channel, user interface and lightning routing. JSON-RPC is used for inter-node communication and user communication. Routing is implemented as routing table that sends payment over multiple hops. It listens for new open channels and protopagates update of routing table. Right now payments propagation to the next hop is not secured by HTLC.

Thunder network has HTLC implemented but no idea how to solve routing problem.

Chris Pacia: If more than 50% of transactions fail to find a route, the lightning network will actually result in more on-chain bitcoin transactions than just paying people directly.

UPDATE Very limited implementation of Flare routing results in 80% success rate in large scale test on AWS.

Sources (general):

Sources (Bitcoin):

Sources (Lightning network):

Sources (Ethereum):

Interesting contracts

Nat traversal

No NAT-punching, UPnP from miniupnp

There is no need for direct connections, so NAT-punching is not necessary. Direct connection with specific nodes should be implemented with Whisper, but those messages can be routed. For sending messages with higher anonymity Tor-like mechanism are planned to be used.