Thanks for the replies Ohad.
One earlier question left unanswered
Do you have specs about what exactly Agora is going to be. I mean other than the
story of Bob and Alice . What kind of assets will Agora allow to trade? Will it feature a full fledged distributed exchange like Ripple? Will it support other market paradigms like auctions or prediction markets?
One more question: there are many references to "chains" in your answers, blog posts and papers.
- There was the blockchain planned for Zennet which was supposed to be used for handling the transactions in Zencoins, was supposed to use PoW, and wasn't supposed to have any inflation, which meant that miners would be rewarded with transaction fees alone.
- In the context of Agora, since Agora is a superset of Zennet, I assume that the originally planned blockchain comes along except that instead of being implemented as a native client, it will be emulated using Tau logic and network built-ins, and now the tokens are called Agora coins, everything else being the same (is that right?). But is it still PoW? If it is do you plan to have Tau open a server socket and let good old mining programs connect to it and do getWork calls?
The workflow of the client can be summarizes as follows:
We have a peer to peer network such that every peer holds an ontology (its rules). Peers speak between themselves at the same language too - they query each other's reasoners, though indirectly. A wrapper around the reasoner recieve the event and query the reasoner "what should I do now", together with the event's information.
Therefore, one can quite naturally add rules to what happens when some query arrives, even locally. The rules doesn't necessarily have to be explicit, as their consequences are calculated by the reasoner.
The query itself can be a computation, some code to run, and even native code: I forgot to mention that we do plan to have FFI builtins. Of course, one has to allow using them, and the typesystem should handle them correctly like such types cannot be Auth types (execution verification).
What to do when a query to run code, how much to charge, under what conditions, all amounts to local rules in the client. Therefore, Zennet's design completely lost meaning, except the pricing formula zennet.sc/zennetpricing.pdf since it all amounts to little piece of tau code. Renting computational power won't need a distinct chain or a side chain, but only the coin it uses has to have it's timestamped ledger. Other data transfer can be done using the DHT layer, or by any other p2p rules.
The builtins will have multiple levels of abstraction. DHT (like get/set) and blockchain primitives (like getWork) will be builtins as for themselves, aside more low level ones like sockets.
Back to what assets Agoras will allow trading, I tend to adhere the principle of letting the users maximum flexibility and minimum intervention. So the goal to implement a stable coin, and a market where participants may place their bids, whether it is computational power or coding or anything, and with a user interface. Readily-made rulesets for common such operations will also be supplied. In addition, there are more applications that need a currency other than markets. The one I'm planning to put focus on under Agoras is a search engine. Remember that with large enough network, tau can crawl the web overnight. And after that night you don't end up with a one line interface tht google gives you, but the whole database is open. Of course computational costs has to be taken care carefully, so we plan to make the search engine self-incentivizing. In general, we'll do our best to make Agoras the best choice as a platform for any application that involves currency.
- In the whitepaper about Tau, you discuss briefly using the block index of a PoW blockchain to serve as the arrow of time. This is a powerful idea but it raises the question of how fundamental the blockchain is to the design. Would you use a blockchain that is implemented independently to Tau as the blueprint for time, and allow Tau logic to query time using a hardcoded built-in?
Yes, but the ontologies will have rich API to the DHT&Chain parameters, and can have a wide control on their flow. A simple example is the conditions for a block to be accepted. Chain builtins will also supply primitives of "before" and "after" that can be Auth types yet external, thanks to the chain's timestamping.
[/quote]
Or would you let the Tau programs query other Tau programs that implement a blockchain node and use whatever they say is the latest index as a time reference? The former would be a more global, reliable and trustable reference but would also add complexity to the base Tau framework and raise the question of how to incentivize the miners of the fundamental chain.
Not exactly, and as above, ontologies will control the chain only up to some extent, but the general flow of DHT&Chain is somehow hard coded.
- In your latest block post as well as many of your answers, you seem to be saying that some of the Tau logic will be somewhat stored and exchanged over a blockchain which will allow nodes to share and publish knowledge. So would that chain be a native chain (not implemented in Tau logic but C++ for instance) or are we talking about a chain that would be created in the Tau bootstrapping file? Is this chain related to Agora or not? Does this chain have economic incentives? If it does what is it? If not how do you ensure that the chain remains consistent?
Information is not stored on the chain - it is stored on the DHT layer, and in case a timestamp is needed, only a merkle root is enough to get into the chain. The root chain has to contain the protocol's definitions (the client's code) and merkle roots for timestamping.
In any case, we always speak about one chain only, and more chains only arise at the scope of pegging them in the root chain, as sidechains do.
- Last but not least you make the parallel in your last blog article between chains and contexts. For example you talk about a "main chain" to refer to some sort of default context. Is the "chain" term in that article still referring to the "chain" in blockchain or is "chain" a linked-list of context elements multiplexed in physical blocks of a real blockchain?
When I say 'chain' on our scope I always mean 'blockchain'.
I could go on, but the main point here is that it's not at all clear (not to me at least) at which level(s) you are planning to introduce blockchains, what it/they will be used for at each specific level, what type of incentive scheme will be introduced to keep these structures consistent accross the network, and how that relates to Tau and/or Agora?
An incentive scheme is indeed an extremely important (if not vital) to the future of the network. Still, the first users have to define it, or better, define how it can be changed. I do have thoughts and opinions about that, and I will vote and propose accordingly over the system.
Thanks for the good questions, will be happy for more.