TAO Framework Roadmap

Welcome!

This roadmap outlines the core features of the TAO Framework. It will be updated regularly to reflect the development, in hopes to give greater insight into progress. Below will briefly describe each of these core features. For more in depth, technical details, please refer to the TAO updates I release on this blog. A big shout out to community involvement in the development of this including Chris, Cain, Paul, Jules, Murdockie, and Shea.

Cheers,

Viz.

1. Trust System — This milestone marks the introduction of the new trust key decay rate, with trust decreasing 3 times faster than it accrues. Replacing the hard 24-hour time limit in September 2018, the new decay rate gives staking wallets greater ability to retain trust and more accurately reflects the effort invested in securing the blockchain.
2. Legacy Mode — Currently in beta, this mode features fast sync times, instant loading, and a small memory and disk footprint. Legacy mode is awaiting final security audits before full public release.
3. Contract Layers — The core of the Tritium Software Stack, these layers provide access to functions such as the recording of assets, managing accounts, decentralized exchange, and the creation of tokens. This is 90% complete pending final revisions.
4. API / SDK — Our API gives developers access to a wide set of features available through a simple HTTP interface. This provides easy access to smart contracts that can be embedded directly into web applications and existing login systems. This is 90% complete pending final revisions.
5. Hybrid Mode — An Enterprise flagship feature, hybrid mode is capable of forming an individual network out of the box, making it a highly useful tool for enterprises that wish to utilize our blockchain technology, whilst retaining high levels of privacy. This feature is currently capable of creating private networks, with hybrid features available on the Tritium mainnet.
6. Ambassador DAO — Our main Tritium++ feature which will govern project funding through a democratic vote. This technology is necessary for a stronger community, consensus oriented budget allocation, and improvements to the overall governance of the network. The DAO (Decentralized Autonomous Organization) will prevent governance issues such as hard forks (Bitcoin vs Bitcoin Cash), and it will create a stronger ecosystem through community participation in decision-making, resulting overall in a more resilient and secure public network. This is 25%. complete and is reserved for Tritium++ as a Post-Tritium hard fork.
7. LISP — The Locator/ID Separation Protocol is an important network protocol that allows one to control their IP addressing, without relying on ISP’s for allocation. It is currently running on the network.
8. Interface / Wallet — The wallet provides modular functionality to allow custom additions such as Binance trading, multi-coin storage, and custom Tritium modules. The wallet is currently complete and awaiting security audits.

1. pBFT + Reputation Channels (L1) — This new architectural component will processes transaction in parallel, using reputation as an additional weight to provide higher security. The transaction speed of L1 channels will vary based on the risk that a merchant wishes to assume, ranging from sub-second speeds to 5 seconds. For higher value transactions, it will be recommended that they receive additional weight from validation on the next consensus layer: L2, reducing transaction speed to 15 seconds plus. This is currently 0% complete.
2. Network Data Sharding — Data sharding is an essential facet of our ledger design in order to achieve long term scalability. Amine, will provide the opportunity for nodes to run in “shard” mode, which will lower their disk and memory usage, even when the network is under high load. This is currently 0% complete.
3. LLD Global File System — The LLD global file system will support secondary files that record assets to be stored and retrieved through network operations, providing a seamless interface for managing assets and data. This is currently 20% complete.
4. Domain Specific Languages — Contract specific programming languages will be provided that will include internal safety mechanisms such as catching overflows to allow more complex contract development, whilst remaining less prone to error. This is currently 0% complete.
5. DAO Voting Groups — This feature will extend the DAO functionality of Tritium++, by the addition of more groups to the consensus mechanism. Groups will be formed of individuals that share a common interest, in order to create a diverse voting structure that reflects many interests in the determination of decisions that affect the entire network. Each group will have a single vote in the DAO. The implementation is currently 20% complete.
6. pBFT + PoS Trust Network (L2) — As an extension to the existing Proof of Stake system, L2 will form the second layer of consensus above the L1. The L2 layer ensures safety and liveness, cross shard communication, and resolves conflicts from the L1 layer. It represents the horizontal chaining of the L1 channels, and is a major step towards a truly decentralized and scalable ledger. This is 0% complete.
7. LISP Multicast Links for (L1) and (L2) — Using LISP, the L1 and L2 layers will have their own Multicast links, therefore packets and transactions will route in constant time no matter how many nodes are part of the system. This is 20% complete, as LISP is currently capable of this functionality, however the L1 and L2 ledger layers are yet to be built.
8. Application Store — Here applications and modules will be able to be shared and sold in a decentralized marketplace. Modules will provide developers the building blocks to create applications. This is 10% complete.

1. Extended Data Sharding — Data sharding in Obsidian will extend to critical network functions, resulting in nodes being required to store only a portion of the overall chain. Note, this is data sharding, not computational sharding, which means once data has been processed, it can be partitioned and stored between nodes. The result will be an increase of data storage as more nodes join the network. This is 0% complete.
2. Decentralized Mining Pool (L3) — This component will use proof of work based mining shares computed from the work performed by the nodes of L2. Consensus will be determined by the largest value of shares + trust, in order to reach the final agreement on the most valid 3D block. This is currently 0% complete.
3. Miner Reputation to improve BFT — This mechanism will offer a variable reward to miners depending on their reputation. It will also lay the foundations for the miner voting group, increase the security of proof of work on L3, and improve the decentralization of the DAO. This is 10% complete, as it is similar to the reputation model of the current PoS system.
4. Extending DAO Voting Groups — The final iteration of the DAO will have 6 voting groups with common interests: Individuals [L1], Stakers [L2], Miners [L3], Ambassadors, Developers, and Enterprises. Together the groups will ratify network upgrades, the allocation and deallocation of funding proposals, and general governance decisions. This is 0% complete.
5. DAO: L1 Voting Group — The L1 voting group will provide voting rights to validators who are new to the network, and therefore do not have enough resources to participate in the L2 consensus. Voting weight is based on reputation. This is 0% complete.
6. DAO: L2 Voting Group — The L2 voting group will extend Tritium’s “Ambassador DAO” and provide voting rights to validators who have reached a reputation threshold. Voting weight is based on reputation multiplied by stake. This is 0% complete.
7. DAO: L3 Voting Group — The L3 voting group will provide voting rights to miners. Voting weight is based on mining power (average weight of mined shares over time) multiplied by reputation. This is 0% complete.
8. LISP Multicast Links for L3 — Shares on L3 will use LISP Multicast links allowing the efficient broadcasting of mined shares, and the acceptance of L2 hashes for computation by L3 nodes. This is currently 20% complete, as LISP is currently capable of Multicast, however the supporting logic is yet to be implemented.