Welcome to the next update of the TAO update series, to continue the journey through the development of the TAO Framework. This particular article is centered around Tritium, our version 3.0 software client.
Are we ready?
Alright, here we go. The following includes a list of all the most recent code changes since the last “git pull origin master”.
Dockerfile | 17 +-
build/SK.d | 13 ++
config/.aliases | 1 +
config/run-nexus | 8 +-
lisp/RL | 9 +-
makefile.cli | 43 + — —
src/LLC/hash/SK.cpp | 38 — —
src/LLC/hash/SK.h | 13 +-
src/LLC/hash/SK/KeccakDuplex.c | 10 +-
src/LLC/hash/SK/KeccakSponge.c | 6 +-
src/LLC/hash/SK/skein.cpp | 2 +-
src/LLC/hash/SK/skein_block.cpp | 2 +-
src/LLC/hash/Skein3Fish/include/skeinApi.h | 2 +-
src/LLC/hash/Skein3Fish/include/threefishApi.h | 2 +-
src/LLC/hash/Skein3Fish/skein.c | 2 +-
src/LLC/hash/Skein3Fish/skeinApi.c | 2 +-
src/LLC/hash/Skein3Fish/skeinBlockNo3F.c | 2 +-
src/LLC/hash/Skein3Fish/skein_block.c | 2 +-
src/LLC/hash/Skein3Fish/threefish1024Block.c | 4 +-
src/LLC/hash/Skein3Fish/threefish256Block.c | 4 +-
src/LLC/hash/Skein3Fish/threefish512Block.c | 4 +-
src/LLC/hash/Skein3Fish/threefishApi.c | 2 +-
src/LLC/include/key.h | 58 ++++ —
src/LLC/include/random.h | 72 ++++ — —
src/LLC/key.cpp | 541 +++++++++++++++++++ — — — — — — —
src/LLC/random.cpp | 149 +++++++ — — — —
src/LLC/types/bignum.h | 18 +-
src/LLC/types/uint1024.h | 16 +-
src/LLD/global.cpp | 20 ++
src/LLD/include/global.h | 25 +++
src/LLD/{templates => include}/journal.h | 0
src/LLD/include/ledger.h | 66 +++++++
src/LLD/include/local.h | 67 +++++++
src/LLD/include/register.h | 51 ++++++
src/LLD/{templates => include}/version.h | 28 + —
src/LLD/templates/filemap.h | 286 ++++++++++++++++ — — — —
src/LLD/templates/hashmap.h | 415 +++++++++++++++++ — —
src/LLD/templates/key.h | 50 +++ —
src/LLD/templates/pool.h | 617 ++++++++++++++++++++ — —
src/LLD/templates/sector.h | 710 +++++++++++++++++++ — —
src/LLD/templates/transaction.h | 65 ++++ — -
src/LLP/hosts.cpp | 30 ++-
src/LLP/include/inv.h | 2 +-
src/LLP/include/legacy.h | 188 + — — — — — — — — —
src/LLP/include/network.h | 9 +-
src/LLP/include/permissions.h | 28 + —
src/LLP/include/tritium.h | 310 +++++++++++++++++++++++
src/LLP/include/version.h | 40 ++ —
src/LLP/legacy.cpp | 71 +++ — — -
src/LLP/packets/legacy.h | 195 ++++++++++++++++++++
src/LLP/packets/packet.h | 82 +++++++++
src/LLP/packets/tritium.h | 173 ++++++++++++++++++
src/LLP/socket.cpp | 74 ++ — — —
src/LLP/templates/connection.h | 247 +++++++++++++++++++
src/LLP/templates/data.h | 47 +++ —
src/LLP/templates/ddos.h | 177 ++++++++++++++++++
src/LLP/templates/events.h | 41 +++++
src/LLP/templates/server.h | 29 ++-
src/LLP/templates/socket.h | 26 ++-
src/LLP/templates/types.h | 440 + — — — — — — — — — — — — — — — —
src/LLP/tritium.cpp | 321 ++++++++++++++++++++++++
src/TAO/API/{ => include}/rpcserver.h | 0
src/TAO/API/rpcdump.cpp | 4 +-
src/TAO/API/rpcserver.cpp | 20 +-
src/TAO/Ledger/block.cpp | 213 ++++++++++++++++++++++
src/TAO/Ledger/checkpoints.cpp | 168 ++++++++ — — — — -
src/TAO/Ledger/global.cpp | 2 +-
src/TAO/Ledger/include/create.h | 38 ++++
src/TAO/Ledger/include/global.h | 4 +-
src/TAO/Ledger/include/supply.h | 10 +-
src/TAO/Ledger/supply.cpp | 50 ++ — -
src/TAO/Ledger/transaction.cpp | 107 +++++++++++
src/TAO/Ledger/trust.cpp | 2 -
src/TAO/Ledger/types/block.cpp | 315 — — — — — — — — — — — — — — —
src/TAO/Ledger/types/{include => }/block.h | 89 +++ — — —
src/TAO/Ledger/types/{include => }/data.h | 0
src/TAO/Ledger/types/include/transaction.h | 66 — — — -
src/TAO/Ledger/types/{include => }/locator.h | 2 +-
src/TAO/Ledger/{include => types}/sigchain.h | 0
src/TAO/Ledger/types/{include => }/state.h | 0
src/TAO/Ledger/types/transaction.h | 226 ++++++++++++++++
src/TAO/Legacy/{types => }/address.cpp | 8 +-
src/TAO/Legacy/{types => }/enum.cpp | 2 +-
src/TAO/Legacy/include/keystore.h | 14 +-
src/TAO/Legacy/include/wallet.h | 30 + —
src/TAO/Legacy/keystore.cpp | 14 +-
src/TAO/Legacy/{types/transaction.cpp => legacytx.cpp} | 31 ++ —
src/TAO/Legacy/{types => }/outpoint.cpp | 0
src/TAO/Legacy/{types => }/script.cpp | 24 + —
src/TAO/Legacy/{types => }/secret.cpp | 6 +-
src/TAO/Legacy/{types => }/txin.cpp | 0
src/TAO/Legacy/{types => }/txout.cpp | 0
src/TAO/Legacy/types/{include => }/address.h | 2 +-
src/TAO/Legacy/types/{include => }/enum.h | 0
src/TAO/Legacy/types/{include => }/inpoint.h | 0
src/TAO/Legacy/types/{include => }/merkle.h | 2 +-
src/TAO/Legacy/types/{include => }/outpoint.h | 0
src/TAO/Legacy/types/{include => }/script.h | 2 +-
src/TAO/Legacy/types/{include => }/secret.h | 4 +-
src/TAO/Legacy/types/{include => }/transaction.h | 2 +-
src/TAO/Legacy/types/{include => }/txin.h | 0
src/TAO/Legacy/types/{include => }/txout.h | 0
src/TAO/Legacy/wallet.cpp | 66 +++ — —
src/TAO/Legacy/walletdb.cpp | 21 + —
src/TAO/Operation/include/enum.h | 54 ++++++
src/TAO/Operation/include/execute.h | 477 +++++++++++++++
src/TAO/Operation/include/operations.h | 83 — — — — -
src/TAO/Operation/include/stream.h | 150 +++++++++++++++
src/TAO/Operation/include/validate.h | 54 ++++++
src/TAO/Register/account.cpp | 27 +++
src/TAO/Register/include/enum.h | 33 ++++
src/TAO/Register/include/object.h | 46 +++ —
src/TAO/Register/include/state.h | 143 +++++++++++ — —
src/TAO/Register/objects/account.h | 100 ++++++++++
src/TAO/Register/objects/escrow.h | 55 ++++++
src/TAO/Register/objects/order.h | 49 +++++
src/TAO/Register/objects/token.h | 116 ++++++++++++
src/Util/args.cpp | 10 +-
src/Util/base58.cpp | 6 +-
src/Util/config.cpp | 8 +-
src/Util/debug.cpp | 53 +++ — -
src/Util/include/allocators.h | 12 +-
src/Util/include/convert.h | 2 +-
src/Util/include/debug.h | 13 +-
src/Util/include/hex.h | 6 +-
src/Util/include/mutex.h | 46 +++ —
src/Util/include/parse.h | 42 ++ — -
src/Util/include/runtime.h | 112 ++++ — — — —
src/Util/include/signals.h | 63 +++++++
src/Util/include/strlcpy.h | 6 +-
src/Util/macro/header.h | 6 +-
src/Util/templates/serialize.h | 388 +++++++++++++++++++ —
src/main.cpp | 189 ++++++++++ — — — — -
133 files changed, 5885 insertions(+), 3980 deletions(-)
Wow, that’s a lot of changes. It’s interesting to look back on it and see how much has been accomplished. As shown here, there was a total of 5,885 new lines of code, with 3,980 lines replaced. This generally means that there was some older code replaced with new, better code, along with almost 2,000 lines of new and fresh code.
Phew!
Now we get to explore what it is that was changed on the more granular detail level, to present to you what will be included in the Tritium update.
Network
Since the last update, there have been some improvements to the Network, or the LLP in our instance. So what is it that makes the network important?
The network is responsible for all end-to-end communication.
If the network was unable to propagate messages, the core peer to peer network would be unable to function. The crypto (LLC) in our case is an overlay for certain network messages to deal with cryptographic objects such as our transactions or blocks. Let us look at the newest results of the LLP in action (you would have also seen this in my Tritium presentation at the 2018 Nexus Conference, linked here: https://www.youtube.com/watch?v=P2pdz4zO38k).
Here it’s good to see requests top out at 197,744 per second as the LLL is the foundation for the TAO, hence the repository name LLL-TAO (shhh, you’ll see the code soon enough if you can find it).
The next aspect of the Network that was formally demonstrated by Dino Farinacci is the LISP architecture, and how it fundamentally works together with the Ledger to provide a safer data layer on the internet. As we know right now, there are a lot of the same problems with identity: it used to be seen that the internet was a place full of fake accounts, trolls, and misinformation. Lately though, we have discovered that the internet can be full of amazing things and incredible possibilities for promoting the ideas of freedom and prosperity.
Make sure to check out Dino’s zoom meeting (Oct 25, at 4:30 PDT) going over this in more depth: https://zoom.us/j/3411938813
Now, one of the reasons the network has been plagued with the negative aspects is that there is no trust layer in the actual system. We have no way to identify someone other than their IP address which is easy to forge or fake by any means. This can create problems, because one cannot reliably know who they are talking to (this doesn’t mean they need to know personal information, but rather consistency across identities). Now, with tying LISP and Nexus together over the ledger, we create the ability to establish a cryptographic identity of the user. This happens over the network with the static EID in LISP, and over the ledger with a signature chain for a user. This becomes very important for reducing fraud and identity theft, which is one of the focal points for Nexus.
Ledger
The ledger consists of the series of events that establish the ownership of any register in the stack. This makes the ledger operate very quickly, since it doesn’t have an incredible overhead in processing requirements beside general cryptographic functions. The biggest bottleneck of the Ledger falls under the LLC (Lower Level Cryptography), as this is where the cryptographic verification happens. The newest results of a Ledger scaling test (transactions only, no blocks in this test) shows over 4.3k tx/s capable of being processed by a single node.
This generates a good picture of what a full LLL stack running real transaction data over it would look like. This shows that the LLD is easily keeping up with the demand of writing over ~1,500 Kb/s (Bitcoin has a maximum of ~1.7 Kb/s). The reason for the slowness in Bitcoin is because of the block size limit of 1Mb every 10 minutes. In this case, we wanted to demonstrate the efficiency of the LLL stack in its capability to handle large loads of data. This particular example shows the maximum processing capabilities of one node, which essentially would be the limits of one L1 state processing channel. The signature aggregation being passed from L1 to L2 through L1 verification nodes in a 3DC would enable greater levels of the scalability without sacrificing the security of a global set of consensus validators.
Signature Chains?
Operating well, with a simple data structure that allows easy indexing and locating of the signature chain transaction history and identification of register ownership. Since the signature chain GenesisID is of a 256-bit number space, it is easy to transfer the permissions of a register to be owned by a signature chain, or simply another register. This sets the foundation now of the Nexus Digital Identity System.
Register
Let’s recap what a register is for better context here:
A register is a data object that changes state through global consensus, or a logical layer application.
Why are registers important?
Computers are state machines by nature. They contain a value that correlates to something on the outside world and change this value based on a sequence of logic. I know this sounds complicated, but in reality, it is quite simple.
If I have 5 apples, I record this number in a register I own to prove I have these 5 apples. When other people can ask me how many apples I have, I can give them my register address, and they can see, ahh, viz. has 5 apples. Now if I sell an apple, let us say through an order I put on the network saying: I’ll give you this 1 apple if you give me 0.1 NXS, then we are able to have state changes recorded and verified by the network, correlated to financial transactions.
This means that if someone were to make this transfer into my contract order it could execute the state change of my total apples of value 5 to value 4, while I send off the apple to the lovely customer. This is a crude example, I know, but the intention of it is not to show secure program logic — but rather, logic that shows the use of a register on Nexus.
Now that we have gotten this out of the way, let us look into what Object registers have been defined as of this update:
src/TAO/Register/objects/account.h | 100 ++++++++++
src/TAO/Register/objects/escrow.h | 55 ++++++
src/TAO/Register/objects/order.h | 49 +++++
src/TAO/Register/objects/token.h | 116 ++++++++++++
Each of these 4 objects are objects that can have the state changed through the ledger consensus mechanism. This is important for Tokens, Escrow, Orders, and Accounts as I shouldn’t be able to modulate the balance of my account without approval from the network. The downside to having the ledger do all the state changing of the registers through the operation codes is the resource requirement of all nodes to process this state change and ensure that it does not create a conflict with another state. It becomes very important to find the balance between logical and ledger state changes, as the network doesn’t always need to know everything that the logical layer is doing, and the logical layer shouldn’t be doing everything that the ledger is doing. This distinction is important for understanding how Nexus Advanced Contracts will scale to levels of requirement for mass adoption.
Raw State registers on the other hand are defined through specifications on the Logical layer. They operate very quickly because nodes only need to write the data, address, and owner of the register. Only the owner of this register will be capable of writing a new state to it if it is not defined as read-only. This allows the Logical / Interface layers (The Application Space) to state record important data to their system such as hashes to IPFS files, private database transactions, or even to create authorization objects to modulate the state of their database based on user actions.
Operations
The following operations are implemented fully, with functionality that executes through the vchLedgerData data member of the Tritium Transaction class:
1. OP_WRITE: Write a new state to a register address given as a parameter to the operation code.
2. OP_REGISTER: Create a new register on the network. It must contain a unique register address, claiming it for this signature chain.
3. OP_TRANSFER: Transfer ownership of a register to another signature chain, or to another register address. This is an important function for establishing the ownership of data by signature chain, and the supply chain that moves it from one owner to the next.
4. OP_DEBIT: Debit a token from a given Account Object Register. This is the commitment of funds operation that gives the recipient the ability to claim with a corresponding credit. The balance of the debit that can be claimed is determined by the percentage ownership displayed through the temporal proof.
5. OP_CREDIT: Claim a balance referencing the transaction debit that was used to commit funds to the given receive account. If a credit is claiming a debit fund from an account they are joint owner of through register chain, a temporal proof is required to satisfy the display of their ownership.
Execute
The method that processes the operation codes is called execute:
src/TAO/Operation/include/execute.h | 477 +++++++++++++++
This method is responsible for the changing of the states on the ledger level, as operations are instructions to the processing nodes to modulate the state of a register through global consensus. The operations and register layers are being designed to be processed on higher locking levels of the 3DC (namely L2), to ensure that transaction processing is broken up across multiple node layers which adds to our ability to scale the advanced contract processing.
Validation
If an operation code is followed by a validation script it will require the validation boolean logic to evaluate to true if an operation code is to be claimable as a proof. What this means is that a certain logic needs to be true for that operation to be claimed. An example would be, “Do not call me past 9:00 PM”, if one was to try and make a phone call the call would not be possible.
src/TAO/Operation/include/validate.h | 54 ++++++
A simple example of this would be relating to debits and credits, where one could put stipulations on the OP_DEBIT requiring the time to be of a certain point in the future. What this would result in is the OP_CREDIT satisfying this script by being submitted past the timestamp that was required. This allows one to program logic beyond the basic operation logic to create greater functionality and customization.
API
The Application Programming Interface will use what is termed JSON (Java Script Object Notation) to submit commands to the nodes that create these state changes in the register, resulting in program logic that gives us the ability to use advanced contracts.
The API will have two components, public and private.
This is important, as the public API will always be developed with public funds through the multiple Nexus Embassies, and provide the required functionality for public use. This will include most of the use cases and programmable logic.
Private
The reason for this is for the integration of businesses that require some of their application logic to be more specialized as far as API functionality, due to the proprietary nature of their developments. This also becomes a “software-as-a-service” integration opportunity for an Embassy to generate additional revenue streams, in which the profits can be recycled back into the core development process.
Logical and Interface
The new Nexus Tritium Wallet is now in public beta. The launch of this has brought an incredible amount of feedback and bug reporting to improve the interface and logical layers. As many of you already know, we provide one common interface for such functionality, where any other distributed application developers will be able to develop their own.
The logical layer is where most of the processing gets done. It is an extended application space through the OSI.
It is important to understand this, because the idea of a blockchain carries many connotations that extend beyond just the ledger. It can coordinate many systems, have private networks that operate and state record off the ledger, access control schemes, state recording based on user actions, and the list can go on. We like to leave this area open for any new type of developers to extend their application space from the conventional OSI design.
What’s in Our Future?
As you can see from this blog post, most of the hard developing is now complete for Tritium. This means that we are in the stage of weaving together code over the network, establishing local databases to handle your sigchain and register indexes, and adding lower level RPC commands to interact with the Ledger, with the higher level API being the interface in the command set.
What does this mean?
Tritium will be released by the end of January, 2019. Yes — I said it — a timeline. As we have noticed over the last year, the removal of roadmaps and timelines did not do what was intended, it only created further uncertainty and rumors in the project. As we are moving into Chapter 3 of our history books with distributed Embassies, newer architecture, and distributed governance models, we felt it was appropriate to augment this with commitments from the development team to set and meet deadlines.
Until Next Time, My friends.
Cheers,
Viz.
