3 major technical problems potentially solved by TAU
By: David Wu
Tags: Serverless, Blockchain, Tau, Proof Of Transaction

TAU uses blockchain, Mainline DHT and android technologies to prove that server-less communication is possible. Each of these technologies has good value, but with major shortcoming. I discuss the nature of these problems and idea to solve it.

History Attack on Blockchain: high mining power holders are able to go back history and recompute the past mining efforts, so that to build an alternative chain, which will cause forking of the established transaction consensus. The bitcoin protocol uses “Proof of Work” energy consumption as barrier to such attack and make the cost of recomputing the history overwhelming costly. Single block can secure up to 50% power of Byzantine Fault Tolerant. A series of blocks can give much higher security. This is why bitcoin community will accept 6 confirmed blocks as immutability. However, “proof of stake” or “proof of transaction”, these light “on-chain” consensuses are exposed to such attack due to no-cost nature of mining. All TAU community chains have such risk as well. In our solution, each peer will maintain a list of friends derived from payments or messages with some level of trusted peers. Friends peers will use hash link to reference blockchains’ hash from time to time in own DAG, which is a tree of own history messages. Therefore, when a history attack happens, each nodes will be able to check their friends references to see which fork is the best to rely on. Peers DAG will require private keys to be altered. This is very difficult for attackers to find most of friends private keys. The whole bitcoin computing power today are not be able to hack a single private key. In short, TAU uses friends social history conversation and reference to firm up the history rather than energy consumption. This is why TAU android app can run thousands of chains mining simultaneously with higher security. The more chains an app runs, the more secure it is. It is like using friends memory to replace energy consumption for history recording. Server-less communication searching latency: without central signal server, a peer does not know when others sending messages. TAU nodes are mostly running on android phones behind firewalls. If a peer has many friends, round robin searching friends will cause latency for new messages when friend list is long. In TAU, rather than round robin, we make each peer to gossip its hearings according to a frequency, based on the status of the phone. In the gossip, a peer could recommend new messages, that were heard of being believed interested to its friends. This is a dynamic programming trick to amortize the searching effort among peers recommendation for reducing the searching complexity from O(n)to O(logN). If a peer has thousands of friends, this approach will reduce the latency to close to constant especially in a big community like a blockchain. DHT routing table pollution: most of the DHT nodes are not working due to being behind restrictive NAT or exposed to malicious Sybil attack. This makes libtorrent code constantly checking healthiness of the routing table, even with this, it is still not safe and causing high data transmission. In TAU, on top of general Mainline DHT, we implemented 2nd DHT using friends relationship as a filter. Through gossiping, each peer will discover friend’s list of friends. The total discovered friends nodes will be the scope of DHT routing table. The content addressing is still follow XOR bucket recursive approach within the scope. On the 2nd level DHT, a peer will always put data to friends node along with generic DHT slower put. TAU dev will behave as a default friend to all peers to help jump-start the communication.

We uses lots of friend list to cope with these known technical problems. Rely on social network, the more service a peer providing to other peers, the more efficiency its own computing becomes. The choice of friends is by each users preferences.