Tau Chain is a peer-to-peer network that self-coordinates multi-party computation using decidable and undecidable logic. One of the developers behind Tau, who calls himself Hunter Miner Crafter explains that the protocol uses an entire readable language to create a unique network of systematic applications. The software uses ontological rules rather than different systems that operate with a turing complete dynamic. This language created could become a tool that ignites the flames of the Internet of Things (IoT) and can collaborate with multiple applications in this field.
“It is much simpler to enumerate what existing systems/application tau can ‘not’ benefit!” — HMC, Tau Chain Developer
Live Bitcoin News chatted with HMC to discuss the Tau Chain project more in depth to gain some information on this very big project. HMC gives our readers a chance to understand the differences between turing complete applications and how their system changes the computational paradigm. The result of these ideas is a “Total Functional Programming Language” and this team wants to show the world what they are creating.
Live Bitcoin News (LBN): What is Tau Chain exactly and what gave your team the idea to create this project?
Hunter Miner Crafter (HMC): Tau is a self-coordinating contract network for secure multi-party computation. It is a generic mechanism for agreeing upon and enacting protocols for secure, verified transactions between parties on spontaneously coordinated overlay networks on the open internet.
The idea for tau is not new and is not originally ours. The notion of using a logical coordination language for SMC protocols over a blockchain dates back to the very first days of bitcoin, and early discussions about possible generalizations of the bitcoin transactional mechanism.
The decision was made to actually implement and execute the idea during discussions about security and long-term stability of the original Zennet network designs, and the possibility for generalizing the idea of zennet to proving over arbitrary information instead of only Linux cgroup statistics for HPC computing. During the discussion, the question was posited as to if there was any “ultimate” generalization of p2p networks. The basic design of tau was given as an answer, and the decision was made to generalize zennet beyond computing resource trade contracts to arbitrary transactional trade under the new name of Agoras (with the zennet name now remaining only as a moniker for a particular contract structure for pricing of computing resource) with the more general underlying infrastructure as a separate project. At this time, the zennet project became three distinct initiatives (Zennet for HPC pricing, Agoras as a more general marketplace backed by a coin token, and tau as the wire protocol for peer coordination.)
LBN: Can you explain how Tau unifies language parameters and their ontologies?
HMC: At it’s core tau uses a general symbolic machine which is grounded in first order predicate logic, based on contemporary semantic web trends (RDF and JSON-LD) and compatible with existing technologies. Above this core layer, tau structures an intuitionistic (Martin-Lof) type system (theory) which extends the RDF-Schema language with sound constructive semantics, a module system, and an IO mechanism. Finally, tau defines an interface between this core logic and a generic theory module describing the fundamental mechanics of a distributed hash table and a blockchain.
On top of these “built-in” semantics, a tau client reads the additional definition from an initial root blockchain which defines an entrypoint for querying the logic, and a mapping for the module system of contextualized specializations of the DHT and chain semantics, as well as details for pegging mechanisms between chains. From this definition, the client is instructed in loading additional ontological definitions as theories, applying the logic defined in these theories to secondary chains for application-specific use cases, and coordinating state change information into a pegging of this secondary chain back onto the root chain.
By this mechanism, additional logical languages (and their backing ontological theories) can be added to the system in an isolated but interoperable way, and enacted as protocols for a transaction between participants.
LBN: Can you describe decidable and undecidable knowledge?
HMC: When we think of logical queries we generally imagine posing some question to some database and receiving back some answer either with some data as results, or some nothing-found negative response. However, Godel and Turing together showed that this is actually only possible in cases of decidable logic. There are some logical systems which are classified as undecidable, meaning that in response to some queries they may answer, in addition to just an affirmative/negative response, with a third possible reply of “maybe, but I need to keep computing more before I can answer.” The real problem is that for some questions this “maybe” answer will persist as the resolution response even after applying an infinite amount of additional computing. Further, it cannot be known after arriving at such a “maybe” response if that response will ever become a yes/no or if it will remain as a maybe forever.
It is known that any logical system which can be shown to be Turing Complete (meaning capable of carrying out any computable logical operation) falls into this category of undecidable logic. This is known as the halting problem.
The tau system explicitly eschews this concern by enforcing that any logical system constructed on top of the type system theory will necessarily be decidable, and halting. It does this by using a relatively recent concept known as Total Functional Programming Language, which is a methodology for structuring a logical language such that all well-formed definitions in that logic will be strictly “total” meaning that any possible input case is accounted for in the definition, as well as strictly “productive” meaning that at any step of a query of the definition some progress toward a definitive result will be made. By this combination of properties, it can be known a priori that any query over well-formed expressions in the logic will eventually reach an affirmative/negative response in some finite number of steps, and will not ever remain in an undecided “maybe” state indefinitely.
LBN: What current systems or real world applications can Tau benefit with its application?
HMC: Anything that currently involves transactions between parties in a virtual space. This may seem like quite a vague and broad answer, but this is because the applicability of tau is really very general.
It is much simpler to enumerate what existing systems/application tau can ‘not’ benefit! On its own, tau cannot (in any way) affect or influence any system or applications that involve interaction/transaction in the physical realm. The only IO (and more generally “side-effects”) that tau is directly capable of are manipulation of DHT/chain state and communication between tau participants. For tau to integrate in any way with a physical system, or for tau to communicate in any way with systems outside of itself, some additional extrinsic component must be utilized on conjunction with the tau protocols.
It is our plan that tau will include some facilities for such an integration with external entities (such as FFI and more general network communication primitives) however these facilities will be implemented at a lower level than the tau type theory, and as such will be considered relatively “unsafe” as tau cannot offer the same level of verification assurances over these interactions. Protocol contexts that use these facilities will carry several caveats, and in our reference client implementation, we will provide strong user interface warnings in an attempt to discourage users from applying such facilities carelessly.
LBN: What does the saying mean “the code is not the rules”?
HMC: For comparison, consider Bitcoin. In Bitcoin, the rules for the network (as set out by Satoshi) are statically defined in the code, as presented by the core developers on GitHub. In such an implementation, the rules and the code are one and the same. The ability to change the rules is exclusively held by those on the GitHub project’s ACL. This creates a centralization of control of the network, as only these developers can officially propose protocol changes.
In Tau, the client code itself only declares a mechanism of interpreting network rules; it does not include the network rules themselves. The network rules are read off of the chain by the client, to instruct that client as to how to participate on the network. In this way, the rules of network participation can be changed without requiring any change to the client code itself, so protocol changes can be decided upon, distributed, and enacted by the participants themselves, directly. This means that there is no central entity like GitHub providing “blessed” protocol, and in turn, this does not necessarily imply that a small group of developers alone hold the rights to propose such changes.
Instead, the details of who can submit what change proposals, and how, as well as the mechanism of consensus to decide upon enacting these changes or not, are all entirely defined in the chain, and are able to be changed (consistent with any existing rules of change) at any time by the participants, without going through any centralized entities.
LBN: When is the estimated planned full release of Tau?
HMC: We plan a full release of tau when the implementation is complete and sound enough to support a secure and stable launch of a genesis block. It is hard to estimate what this timeframe will be. If even the slightest flaw exists in the core of the protocol reference, the network will almost certainly simply self-destruct upon launch, so it is very important that we get the construction right from the start. Because of this, I personally do not try to make any projections of timeframes, because I am well aware that even at the point where we believe we are fully ready for genesis we might likely discover that we actually aren’t at the moment when the network is taken live.
LBN: How will Tau work with the Bitcoin blockchain?
HMC: Directly, in the core implementation, it will not. However, it will be possible for the on-chain logic contexts to either refer to the BTC blockchain state via the previously mentioned “unsafe” IO mechanisms and an external bridge utility, or to define a mechanism of indirect (but “safe”) consensus on the part of the participants as to the state of the BTC blockchain at any given moment.
LBN: How will Tau work with asset management and decentralized markets?
HMC: For assets which can be represented as knowledge within the tau network itself, such asset management will work similarly to other “smart contract” systems where a contract network defines some semantics-over-time around some specific subject acting as a token identifier for the asset, in a context specific to that asset. Further, tau can interoperate with other contract systems with mechanisms similar to how it could interoperate with bitcoin.
LBN: What’s Tau’s overall mission?
HMC: To securely establish a fully general purpose and decentralized proof-carrying network capable of global scale coordination of arbitrary virtual transactions.
Live Bitcoin News would like to thank Hunter for speaking with us and will keep our readers informed of upcoming developments and release dates regarding Tau. The project has a lot to cover as the service has quite a bit of technical tentacles. The Tau Chain team is excited to share the world their latest experiments and hope to provide solid results.
Source: A Tau Developer, Hunter Miner Crafter